Scrum teams usually face the dilemma of determining which stories are good enough to be considered for sprint planning. I'll share some important best practices that I have learned as a Brillio product owner (PO). I work with the team to take care of these things so as to get a user story to a Ready status before I feed it to our team.
Roman Pichler, Agile product management expert, in his blog on Definition of Ready, points out the importance of having clarity on constraints and user interface design for a story. On our team, we take this seriously and make sure that a user story is brought to the attention of a technical architect (TA), and that the TA has spent sufficient time to think about implementation design and possible dependencies with different teams.
We also make sure that any spikes or technical investigations are completed. When this is done, the story is brought to the entire team during a refinement/grooming meeting when the team discusses this story and understands the expected outcome. As the product owner, I emphasize the why
of the user story in the refinement meeting. This gives a lot of context to our development team as to how this user story fits into the big picture.
I experimented with different prioritization techniques but found that having a sequentially numbered backlog, starting from 1, suits the team best. The lower the number, the higher the priority of a product backlog item. This is better than the popularly used Moscow model, whereby you must choose between two "musts."
Other techniques, such as ROI, technical risk, and Kano analysis, are good during the initial stage of backlog preparation. When you actually start working in the sprints, what you need is a clearly ordered backlog that the team can start to work on. Furthermore, if you have an ordered backlog, it gives lot of visibility to the entire team and external stakeholders as to what's going out each sprint.
Story slicing: Horizontal versus vertical?
Story slicing is best illustrated with an example. Imagine we have a small widget that digitizes the onboarding of new clients at a financial institution. This app starts with capturing personal details, financial details, and product details, such as whether the client wants to open a savings account or obtain a credit card.
As a product owner, there are two ways to write user stories about these requirements: One way is to write user stories that limit the scope to different application layers. For example, in the first sprint, develop only the UI layer for personal, financial, and product details. The developers love this kind of scoping! Initially, I made this mistake, too, only to realize later that if you do this, you will never get anything useful out of a sprint.
Eventually we tried a second way: slicing stories vertically, which meant I had a user story that said we would go all the way with the UI, business layer, and database layers of personal details in one sprint. This is a better approach because, at the end of a sprint, you will at least get one component digitized. The other components can still be submitted via a paper-based form.
Another benefit of vertical slicing is that you will learn of the dependencies and hurdles that could lie ahead. In our case, we learned that to submit data to the database, we needed Web services that were shipped by a third-party vendor. This was a dependency that was uncovered early with the second method of slicing, so we started chasing this third-party vendor much earlier.
Story size: How big or small?
Different teams estimate stories by using different methods that range from carrots to T-shirt sizes to the humble story points. Even when teams use the same measure, it is possible that the time taken to implement a 3-point story for one team is very different from the time another team needs for a 3-point story. Hence, the short answer to how big or small a user story should be is that there is no one-size-fits-all. While drafting a user story and later putting it up for estimation, I try to answer these two questions:
- Does this story stand on its own? I.e., Will this deliver tangible business value to my end user?
- Can I articulate all the acceptance criteria for this story so that the team understands the functional context and technical challenges to implement it?
We run a two-week sprint, and what has worked best for us is when we have a story that can be completed within four to five days. Translated into my team's language, that is about 3 story points. During our estimation exercise, when my team says a story is too big (8 story points or higher), I promptly break it down while still answering the above two questions. Sometimes it is possible that an 8-point gorilla can not be split further because the answer to the first question is no. In such cases, we just suck it up and still try to deliver the big guy!
Extent of documentation: What is just enough?
If you are going to write these user stories yourself, then you will be conflicted between being as thorough and as detailed as possible so that you don’t miss a specification and spending too much time actually drafting these stories and missing out on other important PO stuff. Then, if you are working in an offshore Agile setup and delivering software for a client, you also want to make sure that you document everything so that you know why things are the way they are.
Over the past couple of years I have realized that one can never be fully thorough with user stories; a few specs here and there will be missed or will be discovered once development starts. So I try to keep these stories simple, on a one- or two-page Word document, with high-level acceptance criteria and mock-ups (yeah, pictures always help!). There are many tools to create mock-ups. The quickest and the best way is to draw it up on a whiteboard and explain it to the team during backlog grooming sessions. Then, take a snapshot of it and paste it in your user story.
As a PO, if you enjoy a good rapport with the team and if you make sure that everybody understands the context as to why something is being developed, you can always sit alongside developers and suggest minor changes during the course of the sprint, instead of worrying about getting all your specs on a piece of paper. This is why the Agile Manifesto prescribes working software over comprehensive documentation. So, like many other things about Agile, "just enough" is for you and your team to determine!