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. 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 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. 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’s not so with us.

Why We Use Scrum and Why It’s Jira’s Best Friend

Scrum has many advantages, but what I appreciate the most is its predictability when used together with Jira. Jira allows for all-round transparency on all activities and provides comprehensive reports — one can track the tasks remaining, understand the work completed or pushed back, predict releases. It is also easily controlled – 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, teams think in sprints, since they are benchmarks that have a beginning and an end. This way, it’s 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.

Meanwhile, 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 – 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.

No Gaps: Achieving a Continuous Workflow

Now let’s see how we build our sprints. Having no gaps between sprints may seem like an easy thing to do, but the truth is, it’s not. Let’s not forget that every development team and its workflow heavily depend on how efficient the business provides requirements and approves sprint results.

A sprint is a time unit in which project duration is measured. It usually lasts ten days. Why ten? It’s 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.

Days 1-7 are when development happens, when backend, frontend, and QA are working together, taking into account task priorities and blockers. At the same time, based on the change management principles, development team can deliver hot fixes and emergency changes on customer request.

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). During planning, it is 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’s his turn to groom.

Later, on the last day of every sprint, team members report on the tasks they’ve previously groomed. This way, the team is ready for every successive sprint, and they don’t have to waste all day simultaneously grooming and planning.

Days 8-9 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:

1. executes test cases powered by quality assurance engineers;
2. writes automation tests or improves engineering if the project has enough funding or is at an advanced stage of development. 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’s 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.

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 – from Day 1 to Day 8.
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’t change the code, but improve the overall workflow and structure.

We’ve reached Day 10, 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.

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’ve done, report on it, and plan new sprints.

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.

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 – which in my opinion is the best organization approach.

Mind The Gap

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 – shown above – that should help you (and us) avoid chaos and gaps.

Besides, for a team to finish sprints in time, you have to solve two problems:

1) Businesses should specify their demands, so that the team doesn’t fall behind in the sprint.

2) The team should be ready: everyone must understand what the product is all about. If it’s a specific industry – like investments or medicine – they have to be fully prepared and knowledgeable before development starts. They won’t have the time to get into it later.

Scrum Events and Work Correlation

Scrum includes well known set of events that should be handled with an extreme care to achieve a success. They include meetings, planning, and similar get-togethers.

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 – all team members should be present, no matter which part of the project they’re covering. They all have to be on the same page. Otherwise, there’s no sense in planning.

Effective Planning Of The Development Process

The reason why our team works so efficiently is that we all have one main belief: Developers aren’t just coders or testers, they are engineers. It’s all about thinking, about architecture. Time spent thinking about how to make the product better is more important than the time spent coding.

Out 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.

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

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’s better than writing on a whiteboard, which is messy, inconvenient, and only fun for the person holding the pen.

The Secret Weapon: Grooming vs. Planning

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 – 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’s 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.

Afterwards, during 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.

Therefore, grooming is much more efficient than traditional planning sessions when all team members come together and try to plan tasks for a future sprint they don’t even fully understand. And while half of the team tries to figure out additional information, the other half doesn’t pay attention at all, because it’s 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.

On a side note, don’t forget to account for internal company events in planning – days off, sick leaves, or client visits.

The Most Frequent Problems and How to Solve Them

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.

The main question is, what do you do to help team members plan their work and finish everything on schedule? Parallel processes are the solution.

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.

I sincerely hope that you will learn something useful from our insights. To conclude, here are our most important tips in infographic.

I 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’s always better to work with partners who know how to make their own work more efficient and not waste anyone’s time. I hope this guide will help you optimize your processes and win over some great collaborators and partners.

This article about effective work planning in Scrum is written by Nataliia Peterheria - Project Manager at Django Stars. Originally published on Django Stars blog.