The perfect backlog

In the perfect backlog, the product owners elicit requirements from the users and stakeholders using a whole array of techniques, and then they write it up in the form of a user story and put it on the backlog. They don’t determine the best way to solve the problem in the story, but they then go and determine how important it is in priority order and continue consulting with the stakeholders and users to gather more requirements.

Once the story starts to appear on the horizon of the backlog, the business analysts, UX designers and developers have a think about the ways they can solve the need presented. Sometimes the solution is self-evident (perhaps an author wants to see what their article looks like before publishing it – sounds like we need some sort of preview mechanism!), but often it’s not, and the “obvious” solution might actually miss out on a more innovative, better idea (maybe instead of preview we should make the authoring environment look and feel like the published environment). So the business analyst might go and bang the requirements around a bit to make sure the user story is the right one, and then go and find out exactly how we’ll know when we’ve solved the presented problem (the acceptance criteria). The UX designers and business analysts develop some interaction processes and solutions in the context of the whole system, maybe following user centric design and the developers go and check how realistic it would be to build the proposed solution.

These potential solutions are presented to the product owner who decides the one they like the most (hopefully based on the knowledge of the users and stakeholders, but sometimes it might just be the one that has the most whizz-bang features).

Then the business analysts, the UX designers, the developers and the testers get together in a 3 amigos session and turn the acceptance criteria into scenarios which satisfy those criteria in line with the proposed processes and user experience, and everything now meets the ‘definition of ready’ to come into a sprint. Maybe this ‘getting ready’ process is tracked in a sprint, or maybe you have people in your scrum team who spend some time outside the sprint in order to get things ready, but now we’ve hopefully got a solution to a story that can be delivered (to your definition of done) in one sprint.

But getting that perfect backlog is never that simple. Coming up with solutions to problems is fun – sometimes the users think they really know what they want (time to break out the 5 Whys if so, because maybe they don’t want a faster horse), and sometimes the product owner thinks they know the answer (but they should stick to what they’re good at, and leave the solutions to come from the people who do what they’re good at, that’s what they’re there for after all). So it takes discipline.

Scrum suffers from seeing everyone in the team (except the product owner and ScrumMaster) as equal. In reality they’re not. Sometimes they’re specialists, other times they’re “T-shaped” specialising generalists (my favourite type of team to work in), and very rarely is everyone a generalist. But everyone is creative, and you should use the skills they do have to your advantage. Your scrum team are not cogs which churn out software, they’re a team to come up with solutions to problems. Trust really makes an effective team, so trust the team to deliver effective solutions to problems and stop product owners over-working.

Scrum lives and dies by the backlog, and a poor backlog (especially one which is poorly managed) can turn many projects into wagile death marches. Have a look at your backlog – does it consist of problems to be solved, or solutions to be built? If it’s the latter, then in my opinion, you’re doing it wrong.