You’ve probably heard a Scrum Master or a Scrum coach preaching before that ‘the user story needs to be at the right level’. While a user story in Scrum needs to be specific enough to be taken on by the team for implementation (clear WHAT and WHY), it needs to leave enough room for the team to find the best way of implementing it (a loose HOW).
As nothing is as powerful as a good example, I thought the following one would be worth sharing.
In the estimation meeting, this story was presented to the team:
As operations lead, for every log file in the central log directory I want to regularly collect data about the number of newly written log entries per time unit, so that I can use them for trend analysis in Graphite(*) and to spot (upcoming) incidents.
(*) Graphite is a tool for real-time charting of operational data
The acceptance criteria were given as follows:
- Number of added lines in log files is gathered in Graphite
- A graph exists in Graphite presenting the slope
- Newly created log files are automatically presented in Graphite
The team asked a few questions and folks started mulling over it. When we were just getting ready to do the actual estimation, one team member asked ‘Would it be ok to measure the size of the log files in bytes?’. While the PO thought it over, he added ‘That would be easier to implement’. After a brief discussion it became clear that the PO’s objectives would be reached with this alternative way (recording increase in bytes instead of lines of code). The story and the acceptance criteria were adjusted, the story was estimated and the team moved on.
What can we learn from this? First of all, I believe it’s a good sign if team members openly bring up questions like this. In this case, an opportunity to get the same business benefit for less effort would have been missed otherwise.
What was the issue? The way the story was formulated instantly narrowed down the (obvious) solution space available. So how could the story have looked like to be more open? Here is my suggestion:
As operations lead, for every log file in the central log directory I want to regularly collect data about
the number of newly written log entries per time unitthe growth rate of the log volume, so that I can use them for trend analysis in Graphite(*) and to spot (upcoming) incidents.
This way, the team might briefly discuss a few possible approaches (like collecting lines of code, bytes, whatever) in the estimation and work the rest out along the way.
Trust the Wisdom of Crowds, trust your team to handle a certain amount of looseness and you will be surprised. They will often come up with ideas / solutions that you would not have thought of yourself.
I hope this was helpful. Do you have other examples to share?