Agile is about adapting to change. Change is a reality, we can’t avoid it. How we react to change is what will make or break our product development efforts.
For us to be Agile and adaptable, however, we must be able to change direction quickly. Adjust the deliverables after we collect market/customer feedback. Many teams I’ve worked with were doing exactly the opposite!
Teams often get stuck in the “this story can’t be broken down any further” anti-pattern. They push themselves to deliver enormous User Stories, and therefore end up having to do a lot of upfront planning and estimation (both are needed when the work items are very large).
If teams were able to slice work down to very small increments – say, one day or less – then they would not need to spend so much time planning and estimating. They might even be able to adapt during a Sprint, instead of waiting for the end of the Sprint.
If teams were able to slice work down to very small increments – say, one day or less – then they would not need to spend so much time planning and estimating.
Slicing work is the lost of art of Agile. Agility requires it, but many teams fail to do it.
Slicing for Value, the Product Owner contribution
Slicing work is not easy! Teams that try to do it, often come back and say: “we are now slicing our work smaller, but we end up with stories that don’t have value. They are either front/backend stories or they are just a step in a larger implementation”.
This is a symptom of stories being broken down for architecture, skills or other implementation concerns. When teams learn to break down stories for value, this problem vanishes.
If we can break down stories for value, we are able to validate our assumptions and run user-tests, for example. Clinton Keith has a very good example of that in the #NoEstimates workshop. He explains how a project that had taken 18 months in the past, was broken down for value and ended up delivering a user-testing version in less than 2 weeks. This was only possible because Clinton’s team sliced work around the most critical business assumption.
Assumptions, business assumptions in particular, as the boundaries for slicing
From Clinton’s example, it becomes clear that breaking down User Stories around technical architecture or the organization’s structure will not help us. That approach makes it hard to measure progress reliably, and may cause dependency problems that are hard to manage without heavy planning and long, boring estimation sessions.
Instead, what we learn in the #NoEstimates and Product Owner TOOLBOX workshop is that Business Assumptions are the best boundaries for our slicing efforts.
When we can isolate a business assumption (using micro-experiments), we are then able to focus our implementation efforts around that assumption and collect feedback from users quickly.
When we can isolate a business assumption (using micro-experiments), we are then able to focus our implementation efforts around that assumption and collect feedback from users quickly.
In the #PDevTOOLBOX workshops we use the heuristic: “Product Development is continuous Market Testing”, and share tools that help design product development practices around assumption elicitation and validation.
Business assumptions become our slicing boundaries, which helps teams focus on value and overcome technology-driven slicing problems such as heavy dependencies.
The next #PDevTOOLBOX workshops will take place in Tallinn on April 4th and 5th. For more information email me: vasco.duarte@oikosofy.com
As always Vasco – good stuff and very helpful !