A common challenge Scrum teams face is how to create and structure stories such that they deliver customer value within the time box of a Sprint. Stories often end up spanning multiple sprints or they are too technical and task-oriented instead of focusing on value delivery.
A vertical slice “refers to a cross-sectional slice through the layers that form the structure of the software code base.” Vertical story slicing is intimidating to teams when they first experiment with it. Even teams that understand it conceptually often struggle with decomposing their stories small enough while still achieving a vertical slice. Consequently, teams revert back to their old habits of creating user stories that are horizontally sliced.
Join Applied Frameworks Principal Consultant Kim Poremski and explore how to overcome these challenges so your team can achieve value-added results in EVERY Sprint.
Agenda:
1) Discuss the characteristics of a well-formed story
2) Explore common patterns for effective story slicing
3) Learn to identify clues for when/how to slice stories
4) Examine sample stories to practice applying story slicing techniques
***Bonus Q&A***
Kim didn’t just present! Check out the in-depth Q&A with additional answers below.
Original images appear as courtesy of Ben Clay and can be found in their original form here.
Download Presentation
Questions & Answers
Question: Who/which role should prepare and slice stories so they are small?
Kim: Ideally the Product Owner would be the primary person to initially structure and decompose backlog items into small units of value, but ultimately the entire team should have input. The Product Owner would bring backlog items to Product Backlog Refinement and the team would discuss whether they are broken down sufficiently and/or if the appropriate patterns have been applied.
Question: Is slicing into “workflow steps” really vertical? In the example, the user gets no value until they can actually buy something.
Kim: Slicing into workflow steps is certainly the first step – consider it the training wheels – but you are correct that the value isn’t delivered until the purchase can be made. In the presentation I discuss how you need to map out the workflow from end-to-end and then find the shortest path to get from point A to point B. That is where the true value lies.
Question: How do you prevent stories from being too small and divided? Some developers feel like they’d get more “easy points” and don’t want to unite stories that would benefit from being one single story.
Kim: This is an interesting question because it could be an indicator of some ineffective team and/or management metrics practices. Often story points are used to measure team performance and effectiveness. I also often observe organizations using story points to compare teams to one another. This is not a practice we recommend. Story points are specific to each team and should be used as a forecasting mechanism not as a way to monitor team performance. It seems that the team wants to classify tasks as stories so they appear to complete more work in a given Sprint. Typically when this is the case, the team is not united on the outcomes they are providing for a customer, rather they are only interested in their individual output, like widgets on assembly line. A strong Product Owner can assist the team in focusing on customer value (outcomes). If the team is completing most of the their stories in a day or less, they may be too small and task-oriented.
Question: At which point is a vertical story small enough?
Kim: This “sweet spot” of a story being right-sized will be largely team dependent. The short answer is that it’s small enough when the team is confident they can complete it within the Sprint. By complete, we mean fully developed AND tested AND meets the team’s Definition of Done. However, simply being able to fit within a Sprint isn’t enough. For example, if your team has a 2-week Sprint cadence, you wouldn’t want a single story to take the full 2 weeks to complete. You want to decompose stories such that you can complete them in a day to a few days. If your teams uses relative estimation in the formation of story points and you know your team’s average velocity, that can be a good indicator. If a team has a velocity of 18 points per Sprint and your story is estimated at 13 points, it’s likely still too big.
Question: A common pattern is “I want to build out the backend first”, which can take weeks and isn’t directly usable by the user. Can you offer some tips on how to break this scenario down?
Kim: This is what I attempted to illustrate towards the end of the presentation when I provided the example of the two teams that were working on providing barcode scanning capabilities for Health Savings Account (HSA) products. I would be very cognizant of what absolutely must be in place – what is truly the backend infrastructure upon which everything else must be built? Then use the patterns to see if you can segment the backend more. For backend work I suspect that the more common patterns would be variations in interfaces, variations in data, and variations in business rules. There will be some architectural backbone that must serve as the foundation but be careful to classify too much as backend or foundational. For example, suppose a new housing community is being developed. Before houses can be constructed, it is typically necessary to lay electrical and sewer lines, build roads, etc. But how much is just enough? If the community will be built in three phases, you may not need electrical and sewer lines for phases 2 and 3 just yet. If the community will consist of 20 homes, it is NOT necessary for the foundations to be laid for all 20 homes before construction can begin.
Question: Do Kanban teams have an advantage over scrum teams when story splitting?
Kim: I wouldn’t say that Kanban teams have an advantage over Scrum teams when story splitting, rather I would say that for Kanban teams it’s that much more critical. Your focus should still be on producing customer value as quickly as possible but Kanban is setup to be a continuous flow with stringent WIP (work in progress) limits in place. If your stories are too big, you will end up working on them for longer periods and time. Due to WIP limits, your team may be “stuck” until the current WIP is complete. Consequently, you could end up creating a log jam. Keeping stories small enough to be completed in a few days and ensuring they are structured and sliced in a customer centric way will help to maintain a fluid cadence for the Kanban team.
Interested in learning more? Please contact us to learn more about how our consultants can help your organization or
–> Schedule a meeting with Head of Client Delivery, Bob Ternes.