Welcome to Part 3 of 4 on what happens when your Agile Requirements go Wrong. In this blog, I tackle four more ways things can go awry, including my #1 pet peeve when it comes to User Stories. Let’s see what they are…
Gold-plated instead of an MVP and iterating based on feedback
Problem
Gold-plating isn’t necessarily an Agile-only issue – this problem has been around for a long time. That said, I have still seen developers decide (all on their own) to do what I call “drawing outside the lines.” Rather than treating a User Story’s Acceptance Criteria for what they are – boundaries – they treat them more like suggestions and start building things that no one asked for (even though they might be good ideas or enhancements).
Solution
Be sure your Developers understand that while they have free reign to decide how they will solve the business problem or opportunity, the Acceptance Criteria are there to provide guardrails on the scope of the User Story. If a Developer starts doing this, it should be very transparent because you are an Agile team. Every day is an opportunity for inspection and adaptation, and the Scrum Team should nip it in the bud if they see this happen. If it becomes a more significant problem the team can’t handle independently, I suggest escalating to your Scrum Master, who should remedy the behavior.
Horizontally sliced User Stories, rather than vertically sliced ones
Problem
My absolute #1 pet peeve in Agile requirements is when User Stories are sliced horizontally by system lasters. Granted, if you come from a traditional software development background, vertical story-splitting may seem completely counter-intuitive, but it’s not – it’s by design. When you split stories horizontally, you deliver nothing of tangible business value to your stakeholder until you finish all the horizontal system layers. This is the opposite of the intention of Agile.
Solution
Learn how to “slice the cake” vertically. Choose one small capability of a feature and take a thin narrow vertical cut through the layers of the cake. Yes, this means that you’ll have to complete each part of the story from end to end to deliver a fully functional product iteration. It’s going to uncomfortable at first if you’re not used to it. But you’d better get used to it because it’s the right way to document your functional requirements.
Writing user stories in a silo
Problem
Does your Product Owner (or a proxy) lock him/herself away in an office all alone and magically create all the Epics, Features, User Stories, and Acceptance Criteria for the product? I sure hope not, but it does happen. And it’s a problem because it means that there hasn’t been the necessary conversation with stakeholders or the Developers (who are also stakeholders); this causes a lack of transparency, a loss of collaboration, and means that only one person has the product knowledge needed to drive the product forward.
Solution
A User Story is just a promise to have a conversation. Remember the three Cs? If not, they stand for Card, Conversation, and Confirmation. You should never write requirements in a silo. Instead, involve all the necessary parties to define the correct specifications for your product and its features. Otherwise, you may end up building something that no one understands, let alone wants. Make sure you collaborate with everyone, rather than shutting them out and hoarding the product knowledge.
Not questioning what the business needs versus expressed wants
Problem
It’s common for brand new practitioners of Product Ownership (or Business Analysis) to simply take orders rather than use probing questions to understand what is needed. Unfortunately, this leads to a list of “requirements” from stakeholders that don’t have context, aren’t well understood, don’t have buy-in, and may again result in something that no one else wants.
Solution
Don’t just be an “order taker!” Instead, evolve your role into that of a strategic leader. Do your market research. Talk to customers and stakeholders. Perform some root cause analysis using one or more of the techniques available in the BABOK®. Ensure that the requirements you create represent the genuine underlying business need, not just the expressed want of a single stakeholder. By aligning all interested parties and ensuring the work you do ties back to your organizational strategy, you will create a needed and wanted product.
Final Thoughts
Episode 3 of 4 is over. To recap, make sure you set firm expectations about your User Stories and Acceptance Criteria boundaries, so you don’t have Developers go rouge. Also, take thin vertical slices through the system layers rather than slicing your stories horizontally. Finally, ensure that no one writes requirements in a silo and that you’re not just taking orders – delve into understanding the real business needs.
Check back soon for the final installment of this series within a series, the parent story being “Anti-patterns that Doom a Product Owner to Fail.” If you have anything to add, I would love to hear about it, so include it in the comments below!