0 comments
Various 
So how do we use stories for driving the development?
The important first rule is that communication between individuals is better done by explaining and asking rather then using documents as a mean to express the message towards the developers. Don’t let your developers become code monkeys with documents as input and code as output. No flexibility and lots of interpretation problems will come along. User stories don’t allow for this. It’s a reminder for a conversation between developers and business.
So what processes are there when you’re using stories? How are they discovered, sliced and used in your development.
Discovery
Discovery of user stories is a responsibility of the product owner. He or she is externally oriented and focused on selling (or acceptance of) the product, organsations or stakeholders circling around the product. Always looking for stuff that would add business value to the product so the product can:
- Can be sold better
- Has more acceptance by it’s stakeholders
- Reduces operational costs in the processes of stakeholders using the application
This discovery process is often out of sight of a team. Often done by researching the world around the product with questionnaires etc. There also are often investment themes defined by upper management. Often abstract stuff which the product owner needs to split up to usefull additions to the product.
But there is also another moment in which the discovery is done. This is the Scrum demo. The moment the team shows the product, the stakeholders getting all enthousiastic and afterwards (or during) the demo asking the PO if feature A or feature B could also be added. Often a moment the PO needs to remind the stakeholders what else there is sitting on the backlog and rank the newly discovered stories in the list. Better said, discovery is also in the feedback loops. Make sure you implement those loops in your process (maybe even more then only the demo? feedback loops with your real users?).
Slicing
So now we have a lot of discovered stories which would add value. But when telling the developers to build it translation to effort for them needs to be done. Often the story is too large. The product owner needs to hunt together with the stakeholders and team to find sizable packages which can be build in a single day (and therefore will fit in a sprint) and still offer business value if only this single story is implemented. It’s often hard to find these so called salami slices. Some guidelines:
- Split the stories as if there was no sprint after the sprint you are gonna plan it.
- Search manual steps in the process you are automating for. Maybe the stakeholder can do a certain step by hand if only some small support is built in for it.
- Don’t forget migrations. Often when we do not migrate current data building the story has no business value.
- If the story still delivers business value often can only be verified by your stakeholders.
And some criteria where to slice and where not to slice:
- Less data fields storage in the system. For example notes which can be attached to an entity. But streetname without the number would be ackward.
- Less “helpers” in the user interface. Instead of autocomplete fields and search related entity fields just plain simple input of the ID of the related entity.
- Steps which can be done manually in the process.
- Less persona’s support in the GUI.
- No support for a certain (small less valuable) group of people in the UI.
- Initial less performance same functionality.
Richard Lawrence created a beautifull poster to hang on your walls with a lot of other slicing patterns:
http://rslawrence.wpengine.com/wp-content/uploads/2012/01/Story-Splitting-Flowchart.pdf
Slicing also takes place when the product owner and his stakeholders can’t make up their mind which story will be included in the sprint. They can decide to split the stories and take the most important part from both of them.
More on using user stories in sprint, before the sprint and at the end of the sprint in the next weblog posts. After those topics it’s time to take a deeper dive into the more advanced topics.