Welcome to Part 2 of “When your Agile Requirements go Wrong.” In the second blog on this topic, I’ll touch on five more ways that you can go astray with your Agile requirements. Let’s get to it!
No definition of “Ready” or “Done”
Problem
A lot of teams have neither a definition of “Ready“ or “Done.” These are crucial components that help you determine when a User Story is ready to be developed and when the Product Owner can accept an increment. Without a definition of “Ready,” how will you know that the story is truly suitable for development? And likewise, without a definition of “Done,” how will the Product Owner be able to know if what the team built is acceptable?
Solution
If you don’t already have one (or both) of these definitions, STOP what you are doing right now, gather your team together, and create these essential artifacts. A “Definition of Ready” is about the User Story, its Acceptance Criteria, and any other details the Developers need to pick the story up and run with it. The definition of “Done” is about the increment itself, and it generally looks like a checklist for the work to be considered complete.
One side note on the Definition of Done – this list tends to be higher-level than Acceptance Criteria. Typically, items on the “Done” checklist span the whole product and sometimes even the organization.
Missing Acceptance Criteria
Problem
How can a Developer build out a User Story if it doesn’t have any details? The Acceptance Criteria (A/C) are the meat of the story based on conversations with stakeholders; they also define the boundaries of what the story requires. Without having A/C, your Developers won’t know what to build or when to stop building.
Solution
There are many ways to document your Acceptance Criteria (which I won’t dig into now) but suffice it to say you need to have some. Also, remember your audience, and tailor your A/C accordingly. If your Developers don’t like reading lots of words, consider including more visual representations of the requirements. If there a lot of options or complex logic, you could include a matrix. Or, you could simply have a checklist.
One other side note on Acceptance Criteria – depending on your Developers, you may need to adjust the amount of detail you include. Senior Developers may only want the bare-bones version, and they can take the User Story and make it happen. Others may need more information and context to be able to develop the increment. It bears repeating that you should always consider your audience.
Dictating the How rather than the Who, What, and Why
Problem
User Stories should provide the type of user, describe what the user wants, and why the user needs it. The intention of User Stories is not to state “how” to accomplish the user’s goal. That is the Developers’ job. So, if you’re prescribing the solution as part of a User Story, you’re doing it wrong.
Solution
Always include the who, what, and why as part of your User Story. Whether you’re using the traditional User Story format of “As a ____, I want ___, so that ____” or another form such as Job Stories, you still need to make sure all three components are present. Avoid the temptation to provide the solution to the problem or opportunity. Leave that up to the people who will develop it; this can be hard for some people to do, especially if they’re used to including lots of technical details in their requirements.
NOTE: the rule of not specifying the solution also applies to Acceptance Criteria.
Stories that are not “Ready” get pulled into a Sprint
Problem
Do you want tons of back-and-forth and slowed-down development? Then go ahead, I dare you – pull a User Story into a Sprint when it doesn’t meet your Definition of Ready. If you do, I promise that you will run into countless problems. You will constantly go back to your Product Owner or stakeholders with questions. Then, you might have to wait for someone to answer those questions. And you probably won’t have enough information to build anything of value at all.
Solution
Don’t let this happen to you! Ensure the Product Owner (or a delegate) is working at least a Sprint or two ahead of the Developers on managing the Product Backlog. When going into Sprint Planning, always have stories at the top that are “Ready.” By getting ahead of the team with ready requirements, the Scrum Team can be confident that they can develop the stories.
Stories that are too big are allowed into a sprint
Problem
Let me tell you a tale. As a Scrum Master, when I joined an existing Scrum Team, the Sprint in progress had a 40-point story in it! I could hardly believe it. The story also lacked any Acceptance Criteria, which is a huge problem by itself. I couldn’t imagine how that had happened. Then, I took immediate action to prevent that from ever happening again.
Solution
The Scrum Team should have a rule of thumb limiting the size of stories they can bring into a Sprint (depending on the Sprint length, the size of the team, and the maturity of the Developers). For two-week Sprints, my typical limit is 8 Story Points. For longer Sprint lengths with more complex work, maybe your limit could be 13. But I would highly recommend that that be your maximum. The higher the number, the less information you have. I call that a “clue” that the story is too large to be completed within a Sprint. Try to avoid letting stories that are too big into your Sprints.
Final Thoughts
That’s a wrap. Again, there are so many ways that requirements can go wrong in Agile. Ensure you have a User Story that has Acceptance Criteria tailored to the audience. Provide the context for the Developers, not the solution. And finally, don’t try to do work when the story isn’t ready or pull anything too large into your Sprint.
Come back soon for Part 3 of this topic, which is a part of a more extensive blog series on “Anti-patterns that Doom a Product Owner to Fail.” The next part will include more ways requirements can go wrong in Agile.