Creating a Steady Flow of Completed Work
In the Agile Mentor Community, we have agile practitioners from around the world asking and answering some tough questions.
A Scrum Master from the United States turned to the AMC for advice on what to do with a team that’s been practicing Scrum for a number of years, is good at breaking stories down, but continues to be plagued with work coming in at the eleventh hour, rather than a slow and steady burndown of done work.
As you can imagine, we heard a variety of interesting perspectives on this topic from people around the world and with varying levels of agile experience.
Focus on Delivering Value
A UK-based Scrum Master commented that there is too much focus in the Scrum community, and especially from Scrum Masters, on perfecting the burndown chart. She added that the real success story comes from whether or not the team is delivering value each sprint.
A coach from Illinois added, “Am I the only one that has issues with the ‘ideal burndown’ line? There is nothing ‘ideal’ about that line. It’s simply a mathematical line to show a constant rate which has nothing to do with development.”
He said that in his experience, teams get burned by their managers based on the burndown line not looking good. He argued that as long as teams aren’t being plagued with scope creep and are meeting their goals, burndown metrics can be ignored.
A West coast agile coach politely disagreed on this point and said that if used correctly, a burndown chart can be helpful for the team to find areas of improvement.
Dig Deeper into the Issue
An agile coach from Texas chimed in that when a team fails to have a steady flow of completed work, it may be that there are too many large stories, not enough small ones, or that the team is forgetting to update the tool when they complete work.
She suggested challenging the team to see why they are stuck and what they can do to change this pattern. However, if the team is still meeting the sprint goal and delivering value, she’d let it go.
A Virginia-based Scrum Master agreed that he would dig deeper into the issue. He recommended asking the team these questions:
- Is the team relying on an external testing group to meet its definition of done?
- Are the stories interrelated in a way that causes a testing bottleneck at the end of the sprint?
- Are stories being carried over from sprint to sprint because the team doesn’t have enough time to fix bugs that are discovered during testing?
- Does the team think that stories piling up is an issue for them, and have they brought it up during retrospectives?
Check to See If Teamwork Is Happening
A California-based agile coach said he’s seen this happen a million times, and typically it’s because people are working as individual contributors rather than a true team. He suggested looking for the following signs that the teamwork may be lacking:
- Work is being assigned to individual developers.
- The developers are spending the first half (or more) of the sprint on writing code.
- When coding is done, the developer's hand-off (throw over the wall) code to testers.
- Testers test at the end of the sprint, causing all work in the sprint to get done during the last few days.
Use the ‘No Broken Windows’ Analogy
A Scrum Master/Agile Coach from the UK suggested the team uses the analogy of ‘no broken windows’ as their priority before they can begin any new work. He says teams should prioritize work in a sprint in this order:
- Fix broken build/test environments
- Fix broken or failing automated tests
- Fix bugs arising in the sprint
- Complete in-progress stories
- Start new stories from the sprint backlog
Apply the Code-Test-Fix-Test-Fix-Test-Done Strategy
The same AMC member also suggested that the team sets mini-goals within the sprint to encourage steady progression.
For example, on Monday the team might agree that the first release to test in the sprint will take place on Wednesday and that developers will be available to fix bugs late on Wednesday and Thursday morning.
This way of working is a stepping stone rather than an end goal for the team, he commented. With test driven development, continuous integration, and automated test coverage, the team should strive to get to the point where formal releases in a sprint are irrelevant.
To apply this method, the team works in this order:
- Pick a story off the sprint backlog
- Write an automated regression test for it
- Write the code needed to make the automated regression test pass
- Move on to the next story
We hope you learned some new tips and tricks for creating a steady flow of completed work on your team. For more great ideas on this topic and many more, we invite you to join the Agile Mentors Community. Visit www.agilementors.com for more information on membership.