In this article we will discuss 25 story slicing & splitting techniques that every scrum team must know. During story refinemnt meeting, it is critical to slice the stories, small enough, to fit into the sprint.
Following are the topics discussed
In enterprise environment, where software's grows from simple to complex multi tier systems, carving out valuable product increment to be delivered in a sprint become more and more critical.
Getting scrum teams to a common understanding on how to slice valuable stories becomes essential.
Following are the reasons to slice a story
Incremental Delivery is key principal of agile. The end user should receive the working software incrementaly at the end of every sprint. Following images show how the incremental delivery looks like.
Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value. Scrum is a process framework that has been used to manage work on complex products since the early 1990s.
Everyone will agree that a space shuttle is complex product.
Then the question:
How will you build a space shuttle using scrum framework?
In this build space shuttle example, for client, the entire value boils down to that one switch, which he would press to fire up the space shuttle.
Client – PO conversation for buidling Space Shuttle
Client: Can you guys build a space shuttle for me. It will be first of its kind that nobody has build before.
PO: Sure. We can build this product using scrum and deliver it incrementally sprint by sprint.
Client: I want the complete product, individual parts are of no use to me. Space shuttle will be launched only when it is fully ready.
PO: We will be building the product component by component. Each component will add value to the product. We want your feedback as we build these components, to make sure that we are on right track. We want you to participate in the whole process.
Client: Sounds great. In this way, I can allocate budget for each iteration and see the value being delivered at the end of iteration.
PO: That's right. I will create the product backlog. The most critical component guess-o-meter will be at the top priority.
After first sprint...
PO: Team has built the guess-o-meter and tested it successfully. Lets see the demo.
Client: I am impressed. Looks like we need to add more power to this guess-o-meter as I am expecting heavy payload on this space shuttle.
PO: Sure. Let me add that requirement to the product backlog and prioritize it.
After few more sprint....
Client: The space shuttle is really coming along very good. At the beginning, I was not very clear on what I wanted you to build. But with incremental value delivery the product is took shape piece by piece.
There are two level of values
Every increment may not add value to the business or end user but it may add value to the product itself.
Every product increment may not be released to customer at the end of the sprint, but it should add value to the product.
The battery or oil filters inside the car is not directly used by the car driver but they are necessary units for the functioning of the car.
VSUs are the minimum shippable unit which also valuable to the product
For consumers, the end product feature is the entire API service but from release point of potential VSU can be a service method.
Multiple VSU may required to complete the end product feature.
Each VSU can be considered unit of delivery of value and can form a Story.
VSUs may not always cut across technical boundaries. In larger system technical boundaries may define components.
Product Anatomy: products are complex and layerd.
Aggregation Vs Composition
Composition is “Made up of” relationship
Aggregation is “Is Part of” relationship
In aggregation, sometime, each part is a product in itself
Horizontal Vs Vertical
Horizontal or vertical discussion has third dimension “Context”
Determine the value that is being increment to the product
Try not to slice that value in horizontal
In these story slicing technique do not look for recipe for slicing the stories but look for ingredients that will help you to cook multiple story dishes.
Product owner to discuss the epic with development team before even try to take first stab at creating any stories.
During the discussion possible stories will be identified.
This will become input to product owner to create further stories.
Identify business rules. Identify areas where change in constant. Split stories across business rules. Go for the default implementation first and then add business rules incrementally.
Identify workflows in the process. If there are multiple workflows, the split the stories at workflow level and try to further split the complex workflow into simpler workflow and add incremental steps. Path.
Split across interface methods. Useful at API layer.
First implementation takes time but then it can be reused repeatedly for rest of the implementation. Separating stories for the core logic with add-ons.
It's usually easiest to get one right and then move to a collection.
Extract the core simple and minimum implementation from the complex (all at once) scenario. Go for simple implementation first and then build the complex implementation around that.
Treat "and," "or," and "then" and other connector words as opportunities to split. Simplify a condition, or do only one part of a multi-step sequence.
If multiple complex data sets are involved in process then split across data sets by category. If implementation is similar for multiple categories then use repeat efforts technique.
Split the process or (user interface) into multiple parts and then combine at the end. Sometimes the individual parts may not provide business values but they can be valid product increments.
Non functional and usability requirements can be separated in to stories from the functional implementation.
It's easier to defer non-functional requirements. (A common strategy is to set up spikes as side projects to prove out architectural strategies.)
Cross cutting aspects can be separated at architecture design level.
A system that works for a few people for moderate data sets is a given. After that, each step is a new story. Don't forget the load tests!
Multiple operations can be hidden under the ‘manage’ word.
Separating the happy path implementation from the unhappy path or negative conditions can help. slicing the positive test conditions and negative test conditions can help. (If you can't complete the most trivial transaction, who cares that you have great recovery if step 3 goes bad?)
Split by platform like Apple, android, windows, web and devices like desktops, tablets, mobile phones or touchscreens can help. slicing by browser categories also helpful sometimes.
Split by user roles.
External dependencies can be divided and served one at a time. These dependencies can be downstream or upstream dependencies.
Sometimes the ‘How’ part is not so clear to the scrum team to start the development. Research needs to be done before the development can be started. In this situation, it is worthwhile to separate the development from the research. Be aware of who should do the research – product team or development team.
Sometime developing fully automated solution is relatively big work as compared to developing manual version of it. In some situation it make sense to develop manual version first then automate it.
A batch system doesn't have to interact directly with the user.
Start with API only version and add user interface later.
While developing for multiple users you may run into issues like "what happens when two users try to do the same thing at the same time." Focus on single user version first and create separate stories for multiuser scenarios.
Start with basic command line interface first and build fancy graphical user interface separately.
Sometimes the shippable valuable unit is large enough to not to fit in a sprint and can not be sliced further keeping the value intact. In such situation, parts of the unit can developed separately and then assembled. Integration testing to be done after the assembly.
Is it good idea to create spike task in following situations. Spike can be technical work not related to specific story.
Need for proof of concept (POC) before the development can be started
Prepare development environment
Develop technical framework, base libraries etc.
Sometime there is not enough understanding for the work to be done. Or there are some pre requisites to start the work. In such care creating enabler task can help. Enabler task should enable make the specific story small enough to fit.