Agile‎ > ‎

Ready to Burn

posted Apr 13, 2015, 12:40 PM by Anjuan Simmons   [ updated Jul 21, 2016, 6:39 PM ]
I've been holding out on my Development Team. However, I've been doing it with a purpose in mind. Often, the best way to learn something is to experience life with the absence of that learning. Take programming for example. If you're teaching someone who has never programmed before, you may want to jump into teaching them about object oriented programming. However, as their eyes glaze over, you realize that you are confusing them more than educating them. So, you help them understand relatively easier concepts like variables, strings, input/output, reading files, functions, conditionals, and loops. Maybe you'll tease them a little with lists and dictionaries. You'll pat them on the head and send them of to try building a few programs. You smile as they create a few choose-your-own-adventure type games using lists and functions. Then you wait. You wait for them to come back to you and complain about having to update their code in multiple places just to make a small change. Their code is so complex and unreadable that they are thinking about giving up. Then you say, "Ah ha!".


Photo Credit Paramount

You show them how to use classes and methods. They marvel at how they can clean up their code. You teach them constructors, and they squeal with delight. You barely finish explaining inheritance before they start cackling with glee. Understanding object oriented programming was something they could grok and appreciate because they had experienced what its like to try programming without it.

Similarly, there are several aspects of Scrum that I haven't explained yet because I wanted the Development Team to experience practicing Scrum without them. Also, I would have to stop the team for several days if I tried to explain everything I think we need to understand about Scrum. So, I'm taking an iterative approach to improving our practice of Scrum by doling them out in digestible chunks. Based on the Sprint Retrospective feedback, I think we're ready to understand the Definition of Ready and the Sprint Burndown chart.

The Definition of Ready

We've covered the Definition of Done (DoD), and the Definition of Ready (DoR) is a similar concept. Like many aspects of Scrum, the DoR is just a checklist. However, the DoR is used before the sprint even begins. All user stories must meet the DoR before they are analyzed during the Sprint Planning meeting. Like the DoD, the DoR is collaboratively created by the Product Owner and the Development Team.

The DoR evolved in Scrum to address the same concerns shared during the last Sprint Retrospective. This includes items like:

"Feel like there needs to be more time spent on cards before they hit planning poker (UI work, QA, OPS, Documentation)"
"Trouble splitting work for stories, caused us to pull in more points"
"I think we may have moved too quickly to bring in more work at the beginning of the sprint"
"I feel like cards not matching the DoD at the end of sprints will be common and that we need well defined process here" 
Teams often look to the DoD for guidance in creating the DoR. This is reasonable, and you can find our current DoD here. However, a more useful guideline is the INVEST criteria for user stories. INVEST is often useful for splitting user stories, but it also provides good characteristics for user stories of any size. The INVEST criteria recommends that users stories are:
  • Independent, not tied to another user story 
  • Negotiable, based on what we now know and open to change (before the sprint starts) 
  • Valuable, based on the desires of the Product Owner 
  • Estimable, able to be sized 
  • Small, able to fit in a sprint 
  • Testable, able to be translated into QA assets. 
The ultimate goals is to not let anything into our sprint that is not Ready and to not let anything leave our sprint that is not Done. We'll further discuss the DoR during our next Sprint Retrospective.

The Sprint Burndown Chart

The Sprint Burndown Chart is far more canonical to Scrum than the DoR, but it can be a discouraging artifact because it often shows problems before it starts showing success. This is because the Burndown Chart is often a lagging indicator of the team's success at practicing Scrum. In other words, the Development Team is often better than what is currently being shown by the chart.

Ideally, the chart is self-explanatory. The ideal line is formed by dividing the story points we committed to in this sprint by the number of days in the a two week sprint. So, if we completed roughly an even number of story points per day to finish by the morning the day after the sprint, then our work would follow the ideal line.

I should pause here to say that we will never match the ideal line. Never. Ever. It is just a guideline.

The blue bars show the amount of work that is left to be done in the sprint. Every morning I update this chart for the previous day. Any cards in the Done lane are deducted from the blue bars based on their point value. So, this chart will be updated for what happened today sometime tomorrow morning. That is because the blue bar should represent a full day's worth of work.

So, that's the DoR and the Sprint Burndown Chart. I'll share more techniques when the team is ready for them.