The Sprint Backlog

This is one in a series on Scrum Intro. The preceding post is here.

This artifact is different than many suppose.

It is the list of stories and the list of tasks for those stories, that the Team thinks they can get done in a Sprint. (In my mind, the normal sprint should be 2 weeks in most cases, so, in 2 weeks.)

The Sprint Backlog is created in the Sprint Planning Meeting.

The Stories in the Sprint (in the Sprint Backlog) come from the top of the Product Backlog. Again, the Team gets to decide how many stories to pull into the Sprint.

The Scrum Guide describes it a bit differently. The Plan that the Scrum Guide mentions does not have to be a list of tasks for each story.

Having small tasks for each story is a very good discipline that most teams need. But, if they get more successful and want to experiment with that a bit, then fine.

As we said before, the tasks must be small. We want to see (or maybe not see) that each person is making some progress each day. So, the small tasks (or very small stories) make that progress more clear.

This clarity enables the Team to self-organize better. For example, key problems can be identified and attacked.

The Sprint Backlog becomes the Scrum Board, which is a kind of visual management. More specifically, the Scrum Board is a kind of kannan board. So, kannan, or a form of kannan, is baked into every basic Scrum implementation.

The Scrum Board is usually composed of several columns and rows. The columns are often titled: Backlog, In-Process, To-be-tested, and Done. And there is one row for each story. It is expected that only 1 story is “in process” at a time. Well, that level of minimization of WIP (work-in=process) is a bit tight for beginners. So, normally a Team has two stories in process at any time. But in any case, the situation is usually pretty clear from the Scrum Board, or at least after a brief conversation about the Scrum Board.

Some people complain that the Sprint Backlog is micro-managing. And, indeed, often the work is more broken down (for the 2 weeks) than you often find in a waterfall project. But, the Team is not being micro-managed by someone else (or at least that is not the intent).

The Team creates the Sprint Backlog. The Team volunteers for the Stories and the Tasks. The Team is NOT supposed to ver-promise, but only sign up for the work that that data says they have a history of doing. Unless there is a very good reason to believe the Team now can do more. Two examples: Now Person X is back from the vacation that happened in the prior Sprint. Or the SM has fixed impediment Y, and not the velocity should be higher.

Little things are big. And, the bad news does not get better with age.

And so, by seeing the small problems sooner, the Team is able to take corrective action sooner. And the impact is greater.

Is the Sprint Backlog perfect at the moment we complete the Sprint Planning Meeting? NO!

So, we expect the Sprint Backlog to be revised and improved as the Team does the work and gets smarter. So, at least once each day, anyone on the Team can revise the Sprint Backlog. In general, sooner or later a team member should explain why the Sprint Backlog was changed, if only briefly.

The Sprint Backlog is pretty darn useful.

The next post in this series is here.

« « “Path to CSP” – The A-CSM || The Sprint Burndown Chart » »