We sometimes get caught up in the mechanics of delivering software and forget to give the requirements the attention they need. In the agile / Scrum world, the requirements are housed in the Product Backlog (which I’ll just call the “backlog” in this article). There is a pattern I’ve seen over and over in Scrum teams going through an agile transformation, which goes something like this…
The backlog gets its start from something more waterfall-ish, like a Business Requirements Document. We have lots and lots of requirements, and the first idea and approach is that each requirement will be a story – so “our backlog is almost done!” Somebody is given the task of loading up the backlog tool using the cut-and-paste approach, and the newly-minted Scrum Master starts setting up meeting appointments for stand-ups, planning day, review meetings, and the retrospectives. Hey, that wasn’t so hard.
Now the fun starts – the first planning day is full of confusion. What do we work on? How do we know how much to take on? The team is new and is guessing at what they can do in the sprint (their velocity), and the stories in the backlog are hard to figure out and don’t tell a story. What to do?
If I’m brought onto a project that is in this state, the first thing I’ll do is find the Product Owner (PO). If they don’t have someone who is truly acting as the PO, then that is the first thing to solve (but that’s a story for another day). This is where my Scrumism comes in – “you live and die by the backlog.”
Or said a slightly different way, “the backlog is THE thing.” If the backlog isn’t in good order, nothing else is going to go smoothly. You won’t be able to get stories groomed and ready for sprint entry, you won’t be able to articulate what it is you are trying to build, and the Scrum developers will be anxious because they won’t be able to get a handle on the goals they are working towards (remember, this is THEIR future work you are describing).
The backlog describes what is going to be built. It does it in “story form”, so you get to inject what the end users goals and expectations are, right there in the story. The acceptance criteria spell out what needs to be built to meet the story’s target. We still have requirements, but they are in a different sort of wrapper, and are expressed in a way that expects there will be ongoing communications between those developing (the developers) and those representing the stakeholders and end users (the PO). When we have the backlog in good shape, we can start get our work in the sprints to go smoother. When we can have better than a sprints worth of stories groomed and ready for sprint entry, we can start working down further in the backlog to get things arranged and effort estimated (don’t try to add detail too early!). A well-managed backlog is necessary for a Scrum team to work well. You live and die by the backlog.
