The Anatomy of a (Scrum) Sprint
“Work expands so as to fill the time available for its completion”
~ Cyril Northcote Parkinson
One of the acutest sources of Scrum criticisms derives from the fact that a Sprint seems to be arbitrary, and it tends to create moments where some people are busier than others. In organizations with separate Dev and QA, this appears to be particularly common.
These kinds of problems materialize when teams attempt to implement Scrum half way and resist some of its notions that are very important but often misunderstood, overlooked, or ignored completely. In fact, if you are a software engineer in a Scrum team, you have probably been in the following situation once before.
Your team, composed of Developers and Quality Engineers, planned a sprint with a bunch of stories attempting to fill everybody’s plate based on team’s velocity. Respecting the team velocity is difficult because the stories are too big and there is no good way to fill the sprint to the “just right” point. The Scrum Master attempted to convince developers to split stories into smaller ones, pushing the team to make sure that Dev and QA fit comfortably in the sprint for each of the stories. Developers were convinced that it was not possible to split the stories any further (and who are you to debate that), and each engineer ended up with only one very big story filling the entire sprint.
#1 – Hope is NOT a strategy.
The team tortures the estimates to be low enough to not have to split the stories any further; however, everyone knows well that it will be hard to achieve, but hoping to get it done. Interestingly, knowingly assigning low estimates to stories has a long term effect of changing the meaning of a story point, which creates a velocity drift similar to a story point inflation.
#2 – All stories feel new & different at first; regardless, with some effort, planning ahead at a high level is always possible.
The Scrum Master insisted on undergoing a tasking exercise to better refine the estimates, but developers pushed back saying that, due to the nature of the work, it is not possible to task these stories until you get into the code.
“In some cases, it might be possible, but not for THIS kind of work.”
You know the drill. Developers are supposed to write the code, Quality Engineers are supposed to test it. 3-2-1 Go! The sprint starts.
Developers start writing code. Testers don’t have much to do yet, and they “keep themselves busy”. Toward the middle of the sprint, testers get nervous because the code is not done. The clock is ticking. They get louder:
“Where is the code that I am supposed to test?”
#3 – Handoffs are the mother of all evil, second in evilness only to assumptions.
Developers feel pressured. Some ignore the pressure. Some cut corners. Others blame the process. At some point, always too late, developers “hand off” the work to test.
“Here we go, my work is done!”
Testers, shaking their heads think:
“Right… the work is only starting…”
#4 – One sprinter getting ahead gives the team a false sense of progress. All members of the team need to get to the finish line before the race is over!
QA goes to work. First, they get their heads wrapped around what they are supposed to do, then immediately find some low hanging fruit issues. They file bugs. Developers fix them quickly, horrified that they missed such obvious and silly things. After the initial quick finds, testers need some time to understand how the code is supposed to work, what is supposed to do, and how to deeply test it. Issues are filled slowly. Developers feel like they are not busy enough, they feel like they are wasting their time, and testers feel the pressure to meet the end of the sprint. The world is on QA’s shoulders. Developers start pulling-in stories from the backlog to “get ahead” to the work for the next sprint.
The sprint ends. Everybody stops! Pens down! Heads up!
#5 – Building shippable results is everyone’s responsibility
Some planned stories don’t make it. Testers feel responsible. Developers feel cheated.
“I finished MY work, why didn’t it make it???”
Some of the planned stories do make it, but testers had to cut the testing short because they felt the pressure to call them done. Some of the smaller stories are completely and fully done, and everybody feels at least a bit of (bitter) pride in that. A bunch of development work that was “pulled in” is untested and is in an unclear state of execution, and the remaining work is hard to estimate.
#6 – Being sloppy and deforming key aspects of Scrum is like putting square tires on a car. It will fall apart quickly.
The team accomplished 60% of their goals, the exit is sort of depressing, and a new planning session starts after a brutal retrospective where testers complained they didn’t get the code soon enough, and developers complained that their stuff didn’t get tested by the end of the sprint.
No wonder many engineers have mixed feelings about Scrum…. except… this is not Scrum. This is “Sloppy Scrum”.
The issues with “Sloppy Scrum” can be summarized with its symptoms and the most likely root causes:
Most likely Root Cause
|Abrupt handoff phase between Development and QA||Not enough partnership between Dev and QA.||If Development and QA are not working together, you’ll have abrupt and always late handoffs.|
|QA can’t start plan testing until the development work is done.||Poorly defined stories.||When stories are well defined, QA can start planning to test and writing automated tests immediately, even without having any working code.|
|QA is not able to start testing the work until the entire story is dev complete.||Stories are not tasked and/or well planned.||Tasking, when needed, is where the discussion about incremental deliverables of testable code to QA happens. It is not necessary in all cases, but planning the execution of a story is definitely always needed. It is a tool for planning the work on a story, it is a shared checklist for Dev and QA, and it is a tool to communicate.|
|Stories are too large.||Unwillingness or inability to split the stories.||Splitting stories requires work. However, It is PART of the work, with a cost that needs to be acknowledged. It is not always easy to split stories in small testable chunks, but arguably it is always possible. In some cases, it might require too much work to be worth the ROI, but in most cases, it only requires a little effort. Engineers get better at it over time.|
|There is only one story for one person in one sprint||Stories are too large||See above.|
|Sprints are too heavy;
QA experiences a huge “squeeze” at the end of the sprint.
|Stories are too large.||See above.|
|Test falls behind, and development runs ahead.||Team does not completely subscribe to the model that work is done only when development and test are done.
Team members in this situation probably do not share ownership of the shippable code.
|This happens when Dev and QA do not fully internalize the fact that “getting ahead in development” means leaving test behind, and that leaving test behind leaves dangling undone work that does not bring the team closer to the finish line.
The race is won only when the last team member crosses the finish line. The team needs to swarm issues and help each other to make that finish line.
Development, in an agile world, is a team sport.
Well… how should it work then?
A well running Scrum team works together with one single goal: To get shippable work done. It does not work as a bunch of individuals with loosely aligned goals, where everyone is making assumptions that they are going more or less in the same direction as everyone else.
The process must start by writing well-crafted stories, designed to allow developers and testers to build and test a functional body of work during the sprint time frame.
#7 – Agile development is a team sport. The team wins or loses as one.
Splitting work in stories small enough to fit in a sprint is an art that requires work, skill, and craftsmanship. Similar to coding, it is far from being an exact science, but it is (almost) always achievable as long as team members need to commit to do it, and resist the temptation of working independently and in isolation. The time spent in planning the work should be seen by team members as an integral part of the work itself, and not as an unnecessary activity that slows them down.
In some rare cases splitting stories is truly difficult, and not worth the cost. In my experience, when you really try, not being able to come up with smaller testable stories is a rare case, and the existence of that rare possibility should not be a reason not to try. If you don’t try, and if you only see one single way to split the code in testable chunks, it will seem like an impossible task, and you will never get better at it.
#8 – Agile development cannot be rigid.
As part of the partnership between Dev and QA, stories should be often tasked, and always estimated. The tasking helps with the estimation, and also provides a tool for discussing the order of execution of the work necessary to bring the story to a shippable state.
Tasking is optional, but if the Dev/QA partnership exists, tasking becomes natural. As the partnership improves and the team achieves a state of flow, tasking could become unnecessary again, as developers and testers might find other ways to communicate more effectively.
If stories tend to be very large and seemingly unsplittable, tasking becomes a necessary tool to encourage a deep dive into the plan for execution. Scrum teams that work well use tasking strategically and large stories are a clear indication that tasking is needed.
Once you have well-crafted stories split into small chunks, properly tasked and planned, developers and testers can start working on their first task. For a developer, the first task will be, for example, coding of a sub feature, or the dev environment setup. For a tester, it could be crafting a test plan, or writing automated tests (yes, even without testable code).
As tasks get completed by the developer, more QA tasks are unblocked and more and more testable functionality becomes available to test. Since it is all tracked on the Scrum Board, the status is transparent to the team. If anyone gets stuck, it is clear to everyone that one of the stories is at risk and swarming can occur. It is important to note that swarming occurs naturally when there is a shared sense of ownership for the success of the sprint and the delivery of the committed body of work. In lack of that shared sense of ownership, team members will resist helping with the problem at hand.
As QA tasks get done, bugs are filed by QA, and the developer gradually shifts from initial development to a mix of development and ship-stopper bug fixing. As the work approaches code complete and ship-stoppers bugs get resolved, the developer might start a new Sprint-committed story, or could continue fixing non-ship-stopper bugs to push the quality bar up, or could take on some technical debt, or help QA if QA is falling behind. QA continues testing and regressing until the story is deemed shippable. At that point, the developer is either already working on a new story, or doing some polishing touches or technical debt reduction.
#9 – Tech debt is tackled more aggressively toward the end of the sprint to reduce long term costs.
If all of this works like a well-oiled machine, the amount of effort that a developer spends in each area shifts gradually from feature development to bug fixing, to technical debt reduction (polishing, infrastructure work, refactoring). For a tester, the effort shifts from test planning & automation, to feature testing, to regression and tech debt reduction (polishing, infrastructure work, refactoring).
The level of effort in the following graph is higher when the color is darker, and lower when the color is lighter:
#10 – When things don’t go well, the team self-readjusts.
The effort is a gradient, and the sum of the gradients is a constant level of effort throughout the sprint. Nobody should ever be idle or picking up not necessary work. Before that ever happens, the issue is brought up during stand up, and the team self-organizes and addresses the specific issue case by case. There are so many possible cases that attempting to explain every single one is beyond the scope of this paper.