The three phases for user Stories
In my former blog (Best Practices for Agile Scrum
) I concluded that making User Stories takes three phases. It’s now time to put it to practice. For the three phases we created a Trello board for the user stories which we need to refine. Every user story has a checklist for all of the three phases, like: ‘The title of the user story reflects the actual fix’, or ‘The team has figured out and talked about different scenario paths’. The full list will be at the bottom of this document.
Also, you need to have everyone to talk about the subject a lot! If you think you got a silly question, don’t hesitate to ask. Speak your mind and you will see that stupid questions can lead to different thoughts and perspectives and might even lead to better solutions. At least, the one who asked a stupid question, knows more about the user story now. Keep asking questions!
One thing worth mentioning: you don’t need to talk about the solution at this point. There is no need for that. It will come in the sprint itself. (In practice, you’ll find out that each one of you is secretly thinking about a solution, so don’t worry about that)
Phase 1: Use cases
Try to figure out the original goal of the feature. You could ask yourself a few simple questions. Like aren’t we dealing with a solution or a question? Aren’t we making a workaround for a deep underlying problem? Maybe the customer thinks he/she wants the feature, but is going to use it the wrong way. So the most important question here is: what does the customer needs the feature for? As a .., I want to …, in order to …
Phase 2: Scenarios
The team gets to know the behavior best when scenarios are made for the feature. Given …, when …, then … It looks kind of silly, but you’ll see that this is the best way to get familiar with the feature. Try to smell the feature. Try to taste it.
You might come to the conclusion that the feature can be splitted, or is hooked into other functionalities. You come up with additions and deviations. Finally you end up with perfect acceptance criteria, because you got the most important scenarios. And the most important thing is that you’re all on the same page! There are no misconceptions at all. Everybody knows what to expect and everybody knows what the impact is of the features functionally.
Phase 3: Consequences and Risks
Up till now, you cannot estimate, because you don’t know the current situation of the code. What does the code look like? Is it rigid or fragile? Is it rotten or deteriorating? Are there unit, integration or end-to-end tests. In short: how is the current condition of the code and what is the technical debt to overcome?
Now you got a good picture of what your situation is and the team can estimate. It knows quite exactly what they are up against.
But keep in mind that you are still not actively looking for a solution for the feature or problem. That’s a thing you need to do within the sprint. You also don’t need to fully understand the ins and outs of the user stories, it’s only to get really familiar with them.
The trick at estimating is to create yourselves a reference. You should define a reference point on a common and well known feature, for example a feature toggle. This is a real easy feature and you have a good feeling about what needs to be done and what not. You can mark this down as 1 story point. From that perspective you can value other features and estimate based on the feature toggle. You will become good and accurate on that in time. You come to a point and ask the team, how is this feature more or less difficult than the previous one.
During the refinement you have estimated a lot. And if you have done enough estimation sessions, you have enough user stories to fill the planning. So the planning will be a formality. A session in which you seek for transparency between the product owner and the development team and have a confirmation of what you agree to do.
As Defenders we create ourselves an image of how the sprint may look like up front and place user stories in it which we think we can do. During all the refinements we tweak that image. (In Jira, you can create a new sprint and fill it with a bunch of user stories from the top of the backlog)
We started off with the questions who are available in Jira about preparation, added value, sprint product, self-organization and teamwork.
That became boring and eventually nothing interesting came out of it to improve ourself. It was the same old song, over and over again.
What we’ve learned
We tried out a lot of different retrospectives. That contributes on having a fresh mind and seeing things from many different perspectives. The most important thing is: improving. There are a lot of different retrospectives you can do like: the 4L’s
, the 5 whys
, speed boat
, 6 thinking hats
(mostly used for problem solving), and lots more of them.
Retro suggestion number 1
If you look at the work you did, try to sum up the facts.
Where was the collaboration?
What was impeding you?
How would you redo the implementation if you could do it all over again? Where are the tweaks in your process?
I know it’s difficult, but with the right questions, you will come far.
Retro suggestion number 2
Let the team realize that everybody is thinking in an other way.
Let everyone draw a picture of a castle with clouds and landscape. You will see that everybody has a different view
Try to have a developer draw one picture together with a tester by drawing one line at the time swapping between the both of them. So first the tester draws one line and then the developer one in addition to the previous one. You will see that the line the tester made is meant differently than the developer thought it would be for.
Retro suggestion number 3
Show the teams emotions in a graphical way: http://tastycupcakes.org/2013/07/moodgraph/
It reflects what let you feel good. How do you prefer to work? What made you feel good. It’s quite obvious that when you feel good, you implement best!
Differ a lot and it will benefit you! Maybe you are thinking: this is really stupid and childish, I’m not going to do any of this. I can imagine that, but I advise you to just try some things out. You are going to have fun for sure!
Experiment a lot! Try out new things like TDD, BDD, extreme programming. Find out what’s best for your team. What benefits the team and what brings it down? Bring in the fun! Move out the worries! If you stick to these ‘rules’ you will improve a lot!
Remember that to have trust in what will come and what you do, makes the team enjoyable to work in.
Checklist Refinement phases
The team knows what is going on,
The title of the user story reflects the actual fix,
The team knows what the fix is for, or why the customer needs the feature,
The team knows how to reproduce the bug, or how the new feature must work,
The team has created (some) use cases.
The team has figured out and talked about different scenario paths,
The product owner is satisfied with the scenarios,
The team has filled the scope and knows what is out of scope,
The team is sure it can demo the user story self-explanatory at the review.
Consequences and Risks
The developers have a general idea on how to implement it,
The testers know which tests are already there and which ones they should add or alter,
The developers know which unit tests and integration tests already exists,
The risk analysis is filled in.