Welcome to the fourth (and final) blog in the series-within-a-series blog on what happens when your Agile Requirements go Wrong. In this episode, I’ll cover the final four ways your requirements can go awry, along with what you can do to solve the problems. Now, let’s dig in!
An overwhelmingly large Product Backlog
Problem
Is your Product Backlog a mile long? Are there hundreds (or thousands) of User Stories in it? Do you have a list of old stories that were written long ago (in a galaxy far, far away – sorry [not sorry] for the Star Wars reference – I couldn’t help myself)? Do you even have a clue what’s in the backlog? When a backlog grows into an unwieldy lengthy mess, there’s no way you can effectively manage it.
Solution
Sometimes, it’s good to start over. Prune the tree. Use this as an opportunity to reset and realign your product with your organization’s strategy. Create a reasonably sized backlog that is freshly groomed and free of clutter. Ensure that the top 10-20 are stack-ranked in priority, based on your context and business value and risk. Once you’ve done that, try not to let your backlog grow into a dumping ground again – keep refining, and you will be able to manage your backlog better going forward.
Not following the INVEST acronym
Problem
Hopefully, you’ve heard the term “INVEST,” which Bill Wake coined. If you do know about this acronym but aren’t following it, you will have numerous problems. For example, your User Stories will be dependent on other stories, people may treat your backlog like a promise or commitment, you will build things that don’t have any value, you won’t be able to size the stories, your stories will be much too large, and you won’t know how (or be able) to test them. These are some significant issues.
- Independent
- Valuable
- Estimable
- Small
- Testable
Solution
The solution is very straightforward on this one: follow the INVEST acronym. It’s that simple. Keep your User Stories independent whenever possible; if it’s impossible to remove dependencies, sequence the backlog to minimize impact. Remind your stakeholders that every User Story in the Product Backlog is negotiable, and only the Product Owner gets to decide what work to do. All User Stories should be valuable, sized (or estimated), small enough to complete within a Sprint, and testable. By following INVEST, your backlog will be in good shape for your Scrum Team.
Pushing through unclear requirements
Problem
A little bit of ambiguity is okay sometimes, but not when there are glaring open questions left unanswered. Then, when teams decide to push forward, they’ll end up blocked or make assumptions despite not having a clear understanding of the requirements. Not only that, but the team may end up building something entirely wrong, and no one will want it.
Solution
The one piece of advice from my mother that I always harken back to is: “if there’s any doubt, don’t do it.” In the case of unclear requirements, this advice is very appropriate. Do not let this happen to you. As a Scrum Team, if you have any questions, make sure they get answered before pulling that story into a Sprint. Having a Definition of Ready should help alleviate this problem, so make sure you have one, and then stick to it to avoid this situation.
Too many “research” spikes
Problem
If you find that your team has many “research” spikes, you should beware – this is usually a clue that something is wrong and that poor practices are in place. For example, when I joined my current project team, they had a research story for every functional one. It shouldn’t take an entire Sprint to research a story so you can build it in the next Sprint. This will slow you down, and you won’t have anything of value to show at the Sprint Review.
Solution
Like technical stories, research stories should also be few and far between, or they should be tasks underneath a User Story rather than a separate story. It’s rarely necessary to have a separate research Spike needed for most User Stories. Of course, there are some circumstances (such as uncovering something huge that you didn’t already know) that might lead you to create a research Spike, but be sure it’s the exception, not the rule.
Final Thoughts
And… that’s a wrap! The fourth installment in this series within a series is complete. The next topic in the “Anti-patterns that Doom a Product Owner to Fail” is another big one, so I’m splitting it into multiple blogs like this subseries. The subject is the Personality and Behaviors of Product Owners. This one could be a bit touchy because it can be a matter of nature (personality) versus nurture (learned behaviors). Join me again soon for more on this topic.
Psst… if I missed any anti-patterns regarding Agile requirements, let me know in the comments below. I covered a fair few, but I wouldn’t be surprised if I missed some. Thank you for reading!