How one scrum team reached and maintained the ideal burndown line

Robin Moore looks at what a specific, Opencast-led scrum team, in a specific set of circumstances did to move from having a volatile burndown chart to one that fairly closely and consistently tracked the ideal line in just a few sprints.

There is a general question in scrum circles about how closely it is reasonable to expect a scrum team to adhere to the ideal line on a burndown chart during a development sprint.

Here we take a look at what a specific, Opencast-led scrum team, in a specific set of circumstances did to move from having a volatile burndown chart to one that fairly closely and consistently tracked the ideal line in just a few sprints.

For clarity, in Scrum a burndown chart is a graph used to track the progress of a team of software developers during a development cycle or sprint. The vertical access on the left shows estimate of the amount of work a team has committed to complete during that sprint and the horizontal axis depicts the number of days available in that sprint.

The ideal line is a line starting from the top left of the graph and moving down towards the bottom right. It plots work completed by the team in equal daily increments until all the work is completed, exactly at the end of the sprint.

How closely teams adhere to this line can be used to identify and manage project risk early, but can also be seen as a measure of how effective a scrum team is in terms of estimating the amount of work to be done and their capacity to deliver it, in uncertain and complex situations.

A key Scrum principle is that software development teams improve by inspecting what they are doing and adapting what they do, to improve their predictability and productivity, in terms of delivering valuable working software. The main mechanisms they use to do this are the sprint retrospective, where they identify areas for improvement, and the actions they agree to implement in the next sprint, to capitalise on those opportunities.

What type of improvements were made?

To keep things simple, we looked at the number and types of improvement actions the team agreed to implement over a 10-sprint period. We then looked at the changes to the burn down chart and team velocity (amount of work done in each sprint). They fell into four categories, with 77% being things that the team were in control of themselves, their ways of working.

Direction and stakeholder engagement improvements

Stakeholder direction was clear at a roadmap level and we worked with them to agree the concept of a single front door to the scrum team. This was to avoid stakeholders going direct to developers to ask for specific work to be done outside the roadmap or challenge team estimates. We also agreed the principles that the scrum team has ownership of what they would commit to in a sprint and the sprint backlog.

Office facility improvement

The office environment and facilities were challenging, and the team needed basics like functioning Wi-Fi, a large screen TV to allow mobbing, and we also provided a coffee machine.

Development tool improvements

There were challenges around the build pipeline and not having access rights to different environments were identified as problems. Although some of these issues were addressed, many had to be lived with and it was accepted these would be a drain on the team’s resources over time.

Ways of working improvements

The team initially used the mobbing technique do develop software. This helped them to learn the new technologies together, share their different skills sets and bond as a team. Over the course of 10 sprints the team made lots of small improvements in the way they worked which ultimately did have an impact on their productivity and predictability. The areas improved included:

• Communicating concerns around the size of the team to ensure it was understood that bringing in more developers would likely slow the team down.
• Morning stand-ups initially took too long to go around the whole team. Also, on Fridays the team was dispersed meaning we had to do the stand up over a voice only Skype call. A couple of useful improvements were: the daily time taken doing stand-up was cut in half by walking the scrum board rather than going around the individuals. Friday Skype calls were replaced by; doing Friday stand ups on Slack, which was both quicker, more easily understood and more enjoyable.
• New definitions of ready and done were created by the new team.
• The approach to story development and elaboration underwent 5 or 6 improvement iterations over the sprints. This helped improve engagement within the team. Engagement between, developers and testers were further improved by changing seating arrangements and ensuring they discussed bugs before raising them on Jira and the physical scrum board.
• Noise levels were identified as an issue for developer concentration, affecting productivity, because the office was fairly busy with a large scrum team and stakeholders. A number of approaches were iterated to improve this over time.
• Improved engagement between the two teams working on the same code base was achieved by attending each other’s daily stand ups, ensuring development was aligned.

When were improvements identified?

Initially a broad mix of improvement opportunities were identified but once these were addressed the majority of improvements were achieved by making changes to the way the team worked and engaged.

What impact did the improvements have on productivity?

Velocity improved quickly by clearing the environmental impediments. There was a peak around sprint six, where the team worked outside normal timeboxed sprint to hit a hard deadline. It took a couple of sprints for the team to recover from this, as can be seen by a dip in productivity, however the overall improvement trajectory continued.

What impact did the improvements have on predictability?

The first three sprints

The highest variety in terms of action type and volume of improvement opportunities were identified here. The burndown charts were fairly volatile with a number of environmental factors slowing the team and blocking developed code from being deployed.

The next four sprints

A fewer number of actions issues focused on fewer types of improvement that the team could control. It can be seen that the burndown charts are less volatile and moving closer to the ideal burndown line.

The final three sprints

Only a slight decrease in the number of improvement actions but the team tracks much more closely to the ideal line – less volatile and therefore much more predictable.

Conclusion

Clearly a development team needs to have decent relationships with their stakeholders, a functioning office and a reasonable set of development tools in order to be able to deliver working software, but once these are achieved to a workable level, improvements in productivity and predictability would appear to be in the team’s own gift through identifying and making improvements to the way they engage with each other and their approach to development.