Yes, it should be burndown, but it is still racing season (F1 1946, Nascar 1949 or NHRA 1930's when cars went faster than 110 miles per hour in a quarter mile) which has been around a lot longer than Agile (2001, in the Manifesto for Agile Software Development (Agile Manifesto). Often new requirements, adjustments, better understanding or for many other reasons during a sprint, you modify or even create new stories. This makes the burndown chart go from a smooth raceway to a winding road real fast. Instead, consider the advantages of attaching tasks to stories. There are many advantages to this and I want to share what those are. You may find this makes communicating your burndown to management, and even those on your team, much easier and clearer.
The following is a summary of the reasons to stop creating new stories within the sprint once a sprint has started.
1) Adding new stories throughout the Sprint will paint an unclear picture of the actual Burndown rate of the teams' progress. Remember, there are reasons that the solutions required became clearer: Sprint Planning meetings are meant to predict what incremental changes are to be made within the Sprint duration. Adding stories rather than adding tasks will lose that degree of accuracy which was planned ahead of time.
2) The struggle to get to the best solution often takes time and I have found on several occasions the answer that was best could NOT have been found sooner. It was the journey of going through several variations or attempts with down time that resulted in the story being completed within the sprint. The purpose of a Scrum Team is to provide incremental improvements of working software over the Sprint's duration, and utilizing Task instead of Story Burndowns will paint a better picture of resource effort, work that has been completed, and most importantly, work that has yet to be completed, which is the true nature of a Burndown chart.
3) sprints that result in a steady, incremental improvements are between 2 and 4 weeks in length. Anything longer or shorter will result in required changes to either not be met because of a shorter timeline, or with an extended Sprint the changes might not even be able to be implemented in time for a release because of work that is already in progress. During the Sprint's duration, the team will add Task details to Stories, iterative testing will reveal additional requirements, and sometimes you can add more than you expected and you need to keep track of that extra goodness which is why agility is key. By tracking all of these additions as Tasks you retain the plan mapped out in the Sprint stories and keep the original timeline and effort scheduled.
Here are some lessons learned that will let Tasks add detail and accuracy while showing the steady work being produced by the team in the Burndown Chart:
Pre-plan the Stories: Hold a planning session to organize, flush out, talk through and agree to the Story descriptions, the acceptance criteria and what evidence of success or completion criteria among the Product Manager, Scrum Master and Scrum Team.
Create Tasks not new Stories: During the sprint let freedom reign; create, cancel and complete tasks under each story. The number of tasks and the wide range of effort applied to the tasks can be inserted by any team member.
In the diagram we show the difference when adding stories compared to adding tasks. With tasks the burndowns will display team progress clearer
Bad Burndown vs Good Burndown: Notice in Release #1 how the Actual Burndown Rate (solid green line) stays at a constant horizontal line close to the total Story points (dotted green line), indicating that Stories were added along the process preventing the actual burndown of completed tasks. Release #2 is an excellent example of how a burndown should look — dipping below the Ideal Burndown Rate (solid blue line) and eventually rising above the ideal rate when tasks are added to the stories. Release #3, although seems bad from a first glance, actually has a good burndown compared to points within the Sprints. The reason why the line has become more horizontal for Release #3 is simply because that is the current Release and Sprint, and the team has not yet completed all Tasks associated to that Sprint. Once the Sprint has been completed the burndown will look similar to Release #2.
In conclusion, you might wonder what is the difference between a story and a task. These definitions will help your team craft more tasks to add to the sprint backlog. A story is something that is generally worked on by more than one person, and a task is generally worked on by just one person. Some tasks are meetings—for example, have a design review between three team members—and I will still consider that a task rather than a user story.
So, perhaps the better distinction is that stories contain multiple types of work (e.g., programming, testing, database design, user interface design, analysis, etc.) while tasks are restricted to a single type of work. Tell my team what you think and if you put this information to use in your ServiceNow development work. I have three certified Agile Scrum Masters on my team and we are finding great value in making this policy change; once a sprint starts, add only tasks not new stories so your sprint burndown runs straight and fast!
NOTE: MY POSTINGS REFLECT MY OWN VIEWS AND DO NOT NECESSARILY REPRESENT THE VIEWS OF MY EMPLOYER, ACCENTURE.
