I can sense the fear from my colleagues when I walk into a story kick off.
“He is so picky and pedantic!”
“This is going to take all day!”
“All the planning I’ve done will be wasted”
Yes, some story kick-offs I have attended have been very painful for all involved. But why?
We do story kick-offs to ensure that everyone is on the same page when a story is picked up by the development team. All the key stakeholders have a chat which should take around 10 minutes. The objectives are to:
- Make sure everyone understands the story and its scope
- Check that there are no ambiguities or inconsistencies
- Ensure everyone agrees the acceptance criteria
Sitting in on story kick-offs can tell you something about the effectiveness of the team. If there are conflicts that might be a sign that people are pulling in different directions.
There is a famous quote
No battle plan survives exposure to the enemy
In Agile circles this could be paraphrased as
No story written in isolation survives exposure to the development team
Yet, I have seen people trying to do just that. On larger projects it might seem sensible to have feature stories created by business analysts on behalf of the Product Owner. Those features are split into related stories and acceptance criteria will be created. Stories will be allocated to future product increments and sprints.
There is an important component missing here… the development team!
“But they are busy delivering the current sprint and should not be disturbed”
“And we have a team of business analysts to do this sort of thing”
If the development team aren’t involved it is highly likely that something will be missed in the story definition. Waiting until the story kick-off to discover this is too late. This is often the catalyst for conflict and a 10 min chat becomes an hour long argument.
A good question to ask in story kick-offs is “how will you know when the story is done?” The response to this will indicate whether you have a chance of completing the work or whether this will be another never ending story that demoralises all involved. If you see the latter the team must have the courage to recommend changes to the story.
Often there will be resistance to change the story due to the time and effort invested creating it in the first place. Good luck to you when discovering there is a different way to carve up a feature into stories, either to better align with the application architecture or deliver business value earlier. It sometimes seems like the “story creation” team want to get shot of the story, problems and all, and for the development team to “just get on delivering” it, resolving all the problems and carrying all the risk as they go.
Two teams working in this way are not demonstrating Shared Ownership. The story is a means to deliver business value – it is a means to an end, and not the end itself.
Writing good stories is hard and shouldn’t be under estimated. It is everyone’s responsibility to create good stories and everyone needs to be aware that writing good stories needs practice. The development teams must be part of the story creation process and will know when a story is ready for development.
And if you find yourself in a story kick-off and nobody is calling out the obvious issues … you should step up and do it, whether people like it or not.