{"id":512,"date":"2018-12-12T12:50:46","date_gmt":"2018-12-12T12:50:46","guid":{"rendered":"https:\/\/djangostars.com\/blog\/?p=512"},"modified":"2024-11-26T09:05:55","modified_gmt":"2024-11-26T09:05:55","slug":"secrets-effective-work-planning-scrum","status":"publish","type":"post","link":"https:\/\/djangostars.com\/blog\/secrets-effective-work-planning-scrum\/","title":{"rendered":"Secrets of Effective Work Planning in Scrum"},"content":{"rendered":"

Our experiences make us who we are. This guide is a set of personal findings and experiences the development team and I acquired while working on numerous projects.<\/p>\n

Like many other companies, we work in Scrum. But Scrum just gives us rules on how to organize the work process. By trial and error, I tried to polish the formula to organize every sprint as efficiently as possible based on business demands and team capacities. By using the formula, we managed to create a smooth and harmonic process, the product was finished by the end of the project, no time was wasted during sprints, and no team member was left sitting on their thumbs.<\/p>\n

For example, as it often happens when teams use an ill-defined approach to planning sprints, developers do their jobs while testers just sit idly by because they have nothing to test yet. It\u2019s not so with us.<\/p>\n

If you are interested in our approach to planning the software development process<\/a>, please contact us<\/a>, and we can not only answer all your questions but also help with your projects.<\/p>\n

Why We Use Scrum and Why It\u2019s Jira\u2019s Best Friend<\/h2>\n

Scrum has many advantages,\u00a0but what I appreciate the most is its predictability when used together with Jira<\/a>. Jira allows for all-round transparency on all activities and provides comprehensive reports \u2014 one can track the tasks remaining, understand the work completed or pushed back, predict releases. It is also easily controlled \u2013 one can check the work efficiency and whether all tasks are checked off after a sprint, and scheduled planning meetings allow all team members to be on the same page. On top of this, Scrum allows you to break complex projects into smaller parts. Each part is covered in a sprint. Consequently,\u00a0teams think in sprints, since they are benchmarks that have a beginning and an end.<\/strong> This way, it\u2019s easier for them to track work results and formulate and execute tasks. Because making a to-do list for 10 days and sticking to it is a lot easier than for 100 days.<\/p>\n

In the picture below you can compare the Scrum to-do list and the Jira.
\n\"to-do
\nMeanwhile, we should keep our activities planned in advance and have predictions on project continuity. For Jira to provide correct reports, sprints should cover the entire process. To be clear, Jira works in two separate directions. One of them involves calculating finished tasks one by one; the other involves calculating Fix Versions \u2013 little events such as the first test version, the second version, product release, etc. In its backlog, Jira has a list of tasks, and if every single one is estimated in story points, Jira can predict the number of sprints we will need for this particular project based on our known working speed. Therefore, we can provide our clients with an approximate, yet very precise budget and deadline at the initial stages of our project discussions.<\/p>\n

No Gaps: Achieving a Continuous Workflow<\/h2>\n

Now let\u2019s see what sprint planning is and how we build our sprints. Having no gaps between sprints may seem like an easy thing to do, but the truth is, it\u2019s not. Let\u2019s not forget that every development team and its workflow heavily depend on how efficient the business provides requirements and approves sprint results.
\n\"Sprint
\nA sprint is a time unit in which project duration is measured. It usually lasts ten days. Why ten? It\u2019s an optimal duration of an iteration, which is long enough to deliver a working increment, but short enough to be tangible, transparent, and understandable for everyone.<\/p>\n

Bonus – grab your Sprint Planning Checklist<\/a>!<\/strong>
\n
\nDays 1-7<\/strong> of the sprint project plan are when development happens, when backend, frontend, and QA are working together, taking into account task priorities and blockers. Scrum for the front-end and back-end is considered the ideal solution. At the same time, based on the change management principles, a development team can deliver hotfixes and emergency changes on customer requests.<\/p>\n

However, in practice, it is a common situation when some team roles may be blocked by others in the development process (e.g., QA cannot start tests until engineers finish their part). The scrum approach to planning makes it necessary to take into account such situations and minimize chances for them to happen. By that mean, each spare moment in the development process can be used by the team members for an individual grooming. For example, frontend developers can only start working when the backend developers are done. This is why, while the backend developer is still coding, the frontend developer can do some grooming. As soon as the backend developer is done with the code, it\u2019s his turn to groom.<\/p>\n

Later, on the last day of every sprint, team members report on the tasks they\u2019ve previously groomed. This way, the team is ready for every successive sprint, and they don\u2019t have to waste all day simultaneously grooming and planning.
\n\"Average
\nDays 8-9<\/strong> are the time for testing and technical tasks, i.e., no changes are being introduced to the Release Candidate build. This is called the code freeze. On days 8-9, the development team:<\/p>\n

    \n
  1. executes test cases<\/i> powered by quality assurance engineers;<\/li>\n
  2. writes automation tests or improves engineering<\/i>if the project has enough funding or is at an advanced stage of development.<\/li>\n<\/ol>\n

    Automation tests check the product and help accelerate the inspection. Manual checking can take quite long; automatic checking takes less than a day. However, this only makes sense when it\u2019s clear which tests should be automated. Writing and supporting tests is expensive an process, but if a startup has enough funds and wants to get a top-notch product, reasonable automating at an earlier development stage is recommended.<\/p>\n

    If the project reaches the automated testing stage, testing day is moved to Day 9. This means that the team can spend one more day for development \u2013 from Day 1 to Day 8.<\/p>\n

    While the QAs are busy working, the rest of the team can perform technical tasks. They i.e can review old files, clean data, (re)organize folders, etc. They don\u2019t change the code, but improve the overall workflow and structure.<\/p>\n

    We\u2019ve reached Day 10<\/strong>, the day when all the work done during the sprint is deployed on a stage server. The business team tests the features, revises and approves them for deployment. On this day, demo versions of more advanced stages are presented to the business side.<\/p>\n

    In addition, Day 10 is the time for retrospective, reporting, and the next sprint planning. Thus, on Day 10 you can look back at the work you\u2019ve done, report on it, and plan new sprints.<\/p>\n

    Note that Day 10 can never be a Friday. Deploying a product and leaving it unsupervised for two days can be dangerous. Someone has to be able to support it, just in case.<\/strong><\/p>\n

    Afterwards, a new sprint begins from Day 1, and I highly recommend to start on a Wednesday. Then, you can have a code freeze on Thursday night, spend Friday and Monday on testing and technical tasks, and present your demo on Tuesday \u2013 which in my opinion is the best organization approach.<\/p>\n

    Mind The Gap<\/h3>\n

    Usually, the most common problem within a sprint are gaps. If a team consists of more than ten people, not all of them may be assigned tasks that correspond with their competences. The result is chaos. My goal, however, was to create a continuous workflow where everyone knows who does what and when. We ended up creating a system \u2013 shown above \u2013 that should help you (and us) avoid chaos and gaps.<\/p>\n

    Besides, for a team to finish sprints in time, you have to solve two problems:<\/p>\n

    1) Businesses should specify their demands, so that the team doesn\u2019t fall behind in the sprint.
    \n2) The team should be ready: everyone must understand what the product is all about. If it\u2019s a specific industry \u2013 like investments or medicine \u2013 they have to be fully prepared and knowledgeable before development starts. They won\u2019t have the time to get into it later.<\/p>\n

    Scrum Events and Work Correlation<\/h3>\n

    Scrum planning includes a well-known set of events that should be handled with extreme care to achieve success. They include meetings, spring project planning, and similar get-togethers.<\/p>\n

    Despite the fact that the main tool for the implementation of the project is work, Scrum events help organize and plan it. Which is why meetings are so important \u2013all team members should be present,<\/a>\u00a0no matter which part of the project they\u2019re covering. They all have to be on the same page. Otherwise, there\u2019s no sense in planning.<\/p>\n

    Effective Planning Of The Development Process<\/h2>\n

    The reason why our team works so efficiently is that we all have one main belief: Developers aren\u2019t just coders or testers, they are engineers. It\u2019s all about thinking, about architecture. Time spent thinking about how to make the product better is more important than the time spent coding.<\/strong>
    \n\"Goals
    \nOut of their usual eight working hours per day, developers spend 5.5 hours coding at their computers. The other 2.5 hours we spend on daily tasks, groomings, calls with customers, hot fixes or in-between discussions.<\/p>\n

    The truth is, tiny things like these \u2013 fixing a minor bug, understanding a task better, or discussing something with a colleague \u2013 are often overlooked during scrum planning. They happen no matter what, and if you don\u2019t count them in during planning, developers lose time and can\u2019t finish the tasks for which they have only eight hours to accomplish.<\/p>\n

    How do you figure out better ways to work with your team? I suggest that you write types of tasks on small sheets of paper, so everyone can move them around on a table. It\u2019s better than writing on a whiteboard, which is messy, inconvenient, and only fun for the person holding the pen.<\/p>\n

    The Secret Weapon: Grooming vs. Planning<\/h2>\n

    As promised, this is the part where we explain grooming in a little more detail. As you know, while the project is being planned, clients give a list of tasks to the team \u2013 not necessarily for the whole project, but at least for one or two sprints. Grooming is the process of getting deeper into a task that\u2019s backlogged in Jira. To use time more efficiently, every team member picks a task one week before the sprint and asks clients all the right questions in advance, so they have more time to get answers.<\/p>\n

    Afterwards, during agile sprint planning, everyone reports on their findings and shares their ideas on how to work on this particular assignment. Which, of course, makes it easier for the team to understand it, too. By the time a new sprint starts, all the tasks are clear and everyone knows what to do.<\/p>\n

    Therefore, grooming is much more efficient than traditional scrum planning sessions when all team members come together and try to plan tasks for a future sprint they don\u2019t even fully understand. And while half of the team tries to figure out additional information, the other half doesn\u2019t pay attention at all, because it\u2019s out of their field of expertise. To put it bluntly, grooming is effective, equally involves everyone in planning, is less time-consuming, and enables non-stop sprints.
    \n\"Goals
    \nOn a side note, don\u2019t forget to account for internal company events in planning \u2013 days off, sick leaves, or client visits.<\/p>\n

    The Most Frequent Problems and How to Solve Them<\/h2>\n

    One problem many teams have is QA being forced to catch up with the rest of the team, since they can only start deep testing after backend and frontend are done.<\/p>\n

    The main question is, what do you do to help team members plan their work and finish everything on schedule?\u00a0<\/strong>Parallel processes are the solution.<\/strong><\/p>\n

    While QA is testing the built, developers complete technical tasks locally or spend time to automation. And while the developers do their magic on Day 1, QA can check deployed technical stuff. And by the time of the next development phase, everything is ready.<\/p>\n

    I sincerely hope that you will learn something useful from our insights. To conclude, here are our most important tips in infographics.
    \n\"\"
    \nI strongly believe that sharing is caring, which is why I decided to share everything I know about how to better organize the development process. It\u2019s always better to work with partners who know how to make their own work more efficient and not waste anyone\u2019s time. I hope this guide will help you optimize your processes and win over some great collaborators and partners.
    \n

    \n
    \n

    Have an idea? Let's discuss!<\/p>\n\n \n

    \n

    <\/p>

      <\/ul><\/div>\n
      \n
      \n\n\n\n\n\n\n\n\n<\/div>\n
      \n
      \n
      \n \n Your name *\n <\/span>\n \n\n \n <\/div>\n
      \n \n Your email *\n <\/span>\n \n <\/div>\n <\/div>\n
      \n
      \n How can we help you? *<\/span>\n \n <\/div>\n <\/div>\n
      \n \n
      \ud83d\udcce Attach File<\/span>\n Formats: pdf, doc, docx, rtf, ppt, pptx.<\/span><\/div>\n <\/div>\n
      \n
      <\/svg><\/div><\/div>
      <\/svg><\/div><\/div>