Smaller, Smaller, Smaller Stories
As Agile practices have evolved, we’ve made stories smaller and smaller. Great. Smaller stories reduce risk and are more likely to be completed in a sprint. A 13 point story might be risky but split it into three 5 point stories and the risk is reduced. If the team only successfully delivers one or two of the stories, value is still gained rather than none if the single 13 point story is missed. That makes good sense and I like the stories that the Development Team will be working on nice and small for that reason.
But are we getting how we create them wrong? Is the Development Team just presented with a list of stories to discuss and do? Are all the stories created by the product owner as a fait accompli?
When presented with a list of small stories at sprint planning, the big picture or goal of the sprint often becomes lost and the focus is entirely on the detail of each of the small stories. We end up with a list of stories for the Development Team to complete that have no focus and are often not even related. The idea that the team chooses and pulls the stories in for a sprint in order to meet the sprint goal is forgotten, and the Product Owner presents the stories in turn until the team’s capacity is reached.
No goal, just stories
The outcome is either no sprint goal or a very loose and meaningless sprint goal, a list of individual stories and team that is at best cooperative but more likely all working individually on their tasks.
It’s like waterfall in a sprint – “do all these things in this Sprint”. So if you are doing this please stop!
Reset
Let’s reset and think about what we are doing for a minute. Planning a list of stories tends to become output focused, that is, if we finish all the stories then we have achieved our goal. And if we don’t finish the stories then what? Has the team failed?
Rather we should be outcome focused. What value do we want to achieve? What is our goal for this sprint? How do we achieve that goal and deliver the required value?
I joined a discussion on value recently, lead by Allan Kelly from Allan Kelly Associates, and one of the points he made was we should approach valuing and bidding for work as “What can we do for X amount that achieves the desired value?” where X amount is the proposed budget by the customer, rather than “This is our proposed solution, and it will cost Y”.
Using this as an approach when planning work in the next sprint also makes sense. We are trying to deliver value after all and have a fixed cost of 1 Sprints effort, so asking the question “What can we do to achieve this Sprint Goal and deliver the desired value in the next sprint?” rather than “Can you complete all these stories in the next Sprint?” is a better approach.
Start Sprint Planning with a Sprint Goal
A lot of teams have got into a position where the Product Owner decrees the stories and the team just do them. This is a very anti-agile approach.
Stories should be the start of a discussion between the Product Owner and the rest of the team, not a list of demands or requirements. We should start with presenting a proposed Sprint Goal in Sprint Planning, rather than presenting a list of small, individual stories.
And what is the goal? It is the change or new functionality the Product Owner deems to give the highest value based upon the current needs of a customer or user, that is, what he/she would like to be achieved overall in the next sprint, taking into account where we are after the previous sprint in the development of the product increment.
And a great way to present the goal is in the form of a big or epic story. This story defines the desired outcome, what value will be delivered for for whom and is supported with more details such as user journeys or user scenarios as required.
A big story gives the whole picture, it has not been sliced it into smaller more granular parts yet, so it allows multiple options to be discussed and proposed. It starts a whole discussion on what it is and how to achieve it.
It also encourages the team to work collaboratively and gain a collective ownership of the goal. If everyone is working on the same story, for the same goal, then they are going to be interested in what the rest of the team is doing, not just on their little bit.
Involve the whole team
To do this we need to get the whole team involved in discussing how to achieve the proposed goal. And I mean the whole team, not a subset of lead this’s and lead that’s. I’m assuming multi functional teams here too. If you only have developers and testers in your team then borrow the necessary skills from elsewhere for the discussion and think about who you really should have in the team.
Give the team time to workshop the goal through. Lots of time. All day if needed or at least half a day. Let the discussion be free ranging. No ideas or points are bad ideas and encourage everyone to contribute.
If assumptions can be validated quickly, this should be done as early as possible. Can you call some one and ask there and then? Opinions are harder to quantify but try to if you can. Beware of the HIPPO (the highest-paid person present’s opinion) overriding all other opinions, facts and assumptions.
The use of a Narrative Canvas is useful to link assumptions, facts, opinions to the goal and to link the goal to the options and consequently the actions required to make it happen.
Another option is to use Roman Pilcher’s Sprint Goal Template
Propose multiple options
The team should propose multiple options for a solution. It’s amazing what options can be proposed and they are not always what was expected. Data migrations for instance: developing a data migration system is expensive so would it be cheaper and easier to outsource it to be completed manually?
Discuss and evaluate each option. Using a value v effort map can help with this.
Experiment and Prototype
If the Product Owner and team can’t identify on a single best option then make it the sprint goal to experiment and quickly prototype the finalists to see which the users like best. Time spend doing this and getting feedback is invaluable and far better than ploughing on with the wrong option.
Or define quick experiments and prototypes to validate assumptions and prove whether opinions are founded on fact or fancy.
Collectively create the Sprint Backlog
Once you have a chosen option (or options), as a team break it down into the small stories or tasks needed in order to complete the goal.
It is these stories or tasks that should be small. An maximum estimate of one day to complete a task is good idea so it is quickly apparent there is a problem brewing.
Estimate whether these can be completed in a single sprint or not using capacity and velocity etc. If not, evaluate the solution and stories/tasks against the discussed goal again to see how it can be further split or whether some stories or tasks can be dropped and still deliver the goal.
And finally agree the Sprint Goal as a whole team based upon the outcome of all of the above. This could potentially be quite different to the originally proposed goal from the Product Owner.
Be collaborative not imposed upon.
So in summary:
- The Product Owner brings a proposed goal to the team in the form of a large story that describes the outcome required, along with any other supporting material, rather than a list of predetermined stories.
- The whole team discusses the goal and work outs what options are available to achieve the goal.
- The team collectively agrees which option or options to run with in the next sprint.
- The whole team breaks the goal into stories and tasks that will need to be completed in the sprint and that will deliver the value requested in the goal.
- The whole team agrees the final Sprint Goal.
Sprint Planning using a goal provides a more a collaborative approach where the team as a whole has discussed, defined and agreed the work required based upon that goal, rather than a list of stories being pushed/imposed upon them. This gives the team greater ownership of the work required and encourages more collaborative working practices during the sprint as they have one single goal to achieve together. It reduces risk and helps make teams great.
Give it a go.
About the Author
Martin Boler is an experienced freelance Agile Delivery Manager, Scrum Master and Agile Coach. He has been practising and promoting agility in the work place for over 12 years for organisations such as NHS Digital, Travelodge, Kingfisher, Nokia, Virgin Atlantic Airways, British Gas and Flybe. He can provide training, coaching and delivery management on a freelance basis. If you want to know more please contact him here or visit www.xcitedevelopments.co.uk.
