If you’re applying the scrum methodology to a development project, then at some point you’ll need to translate user stories into something resembling a list of functional requirements. The way many agile experts explain this transition is that you have to move from considerations of what you want to do onto plans for how you’re going to do it.
Ideally, the product owner figures out the what, while the architects, developers, and quality assurance people take responsibility for the how. The process behind this hand-off is easy to describe in the abstract, but there are a number of ways to implement it in practice—some more effective than others.
The variability in approaches comes about because, as any novice scrum team quickly discovers, the framework leaves a lot of important questions unanswered. In the case of user stories, these questions mainly focus on the role of the product owner at the various project stages and the level of detail required for a viable list of acceptance criteria.
Many of the answers simply have to be worked out in the doing. But there are a few missteps that are frustratingly common, and we hope to help neophyte scrum teams steer clear of these mistakes by briefly exploring the reasons they occur.
In overview at least, the roles and framework are already in place for you: you start with a basic scope of the higher-order plan for the overall application, then in backlog grooming sessions, and to some degree in sprint planning meetings, the product owner chooses the next user story and starts working out the details.
The format of each user story is standard: “As a …, I want to…, so that….” So you have an actor’s role, an action, and an outcome. This gives you the answer to the question of what the feature is being designed to do (plus the who and the why). Again, it’s the product owner who chooses which user story to focus on for each sprint, and it’s the product owner who fills in those three details.
But that still leaves you with some questions:
There are myriad viable ways to answer these and other important questions, and to some extent you’ll want to decide case-by-base, and decisions will also vary from team to team.
Still, having gone through the process ourselves as many times as we have, we can offer one big recommendation that will save you a lot of headaches: if at all possible, work out what will be expected of the product owner before the first sprint. Set and align expectations in advance.
One of the most predictable problems you’re going to run into in your agile projects is that the product owner will be less responsive than would be necessary for an optimally efficient process. You may (probably at several points will) discover that your point person on the client side simply hasn’t thought through a given user story in enough detail. You may also find that your team needs clarification on some of the details of the acceptance criteria in the middle of a sprint, but you can’t get ahold of the designated representative. Do you keep moving ahead with development? Do you sit on your hands? Or do you pull another user story to get started on?
A lot of time gets wasted and a lot of extra work gets done in these scenarios. One of the underlying causes is that product owners are busy people; the development project usually isn’t the only thing they’re responsible for. But the other reason is that people, even your fellow IT people, have vastly different ideas about what it means for a project to be agile.
You may assume that an IT person who agrees to a scrum project is willingly signing on for the intensive involvement it calls for. Even within the most standard parts of the scrum framework, however, there’s plenty of room for varying levels of involvement on the part of product owners. So make sure the parameters your team feels are necessary for a successful project are properly lain out before project kickoff.
The rule of thumb is that the more experienced the scrum team is, the less detailed they need the user story and acceptance criteria to be. This is because team members hone their intuition over time for what the client is hoping to achieve with each feature.
Importantly, with experience, and bolstered by input from members with diverse roles, your team will learn which questions to ask about a user story to get to an adequately comprehensive list of acceptance criteria. Quality Assurance people can be especially useful in this stage of the process because they’re thinking in terms of all the test scenarios and edge cases they’ll be expected to cover.
Another factor that will influence the amount of detail you’ll need as you go from the what to the how is the product owner’s general level of responsiveness. And this is another reason why you want to align expectations upfront. Product owners seldom come right out and say they want minimal involvement in the project, but with some experience you’ll be able to gauge their commitment to remaining accessible over the course of development.
The balance you strike is important because acceptance criteria bring you right up to the border separating the what from the how. With the proper level of involvement on the product owner’s part and a well-balanced list of criteria, you can achieve true agility. If the product owner hands over a detailed list of requirements and then disappears, you’re really just doing waterfall in two-week bursts. But you need to keep in mind that this is what some clients expect.
An extra hint about good acceptance criteria: you’ll avoid a lot of ambiguity and confusion if you stick to a standard template like the one for user stories. The format we use is “Given X, when Y, then Z.” So you have two conditions and an expected outcome. We find this template encourages the right mindset for the product owner and achieves the optimal balance between precision and agility.
Another mistake beginning scrum teams commonly make (including our own back in the day) is to forget that each sprint is supposed to result in a feature that brings value to the user. So, if the product owner looks at the deliverable and has no idea what to do with it, then you’ve done something wrong.
What you’ve probably done is slice the user story horizontally instead of vertically. A horizontally sliced story may entail setting up a database that will be used to support all subsequent features. What you’re doing here is essentially laying the foundation for later work—but how does that bring value to the product owner? Of course, it may be valuable down the line, but this type of planning in advance takes us back into waterfall territory.
Instead of building the entire database layer for a web application during one sprint, for instance, then maybe building another layer on top of it, such as an API, and then finally adding a user interface, you want to focus on a vertical user story slice, one that includes all these layers.
This is counterintuitive at first, like making a layer cake one wedge-shaped piece at a time. But it’s the only way to establish a continuous flow of value to the user, which is in turn the only way to establish a continuous flow of feedback to the development team.
When you’re baking a layer cake, you know what the ultimate shape will be. But, when you’re using agile development methods, you don’t know precisely what the final product will look like, and any time spent assuming the shape could result in a huge amount of waste.
Other posts on scrum mastery: