One of the key concepts of Scrum is Backlogs, a product and a sprint backlog. Scrum would like our product backlog to be:
While these are good principles and are very useful there are some more i have come to value from working with one particular team. Thanks team
Visible and Visualise
We decided with the initial idea from @clempickering to visualise and track the size of the ready for sprint elaborated backlog. This gave us a visible measure which we could update daily and place on our sprint board. This made it very obvious if we needed to take action as a team to place more effort on the refinement/grooming/elaboration process.
What were the signals where we needed to take action?
When have to few stories to fill a iteration. This particular team needs around 10-15 stories per iteration. Simple solution we need to spend more time as a team elaborating stories during the iteration.
When we have too much elaborated we are storing inventory. These cards are likely to decay, the team is likely to lose the understanding of the task and the card may need re-elaborating. Gojko Adzic and David Evans talk about decay of user stories in his book Fifty quick ideas to improve your user stories. This leads nicely into my next point, Gojko talks about putting an expiry date on each story we have done something similar….
We also dot our cards, one dot is added each iteration the point of dotting the cards is to assess age. If a card is too old the team again is likely to lose understanding of the task at hand. Although we may be at an optimum level of elaborated stories there may be some which are not prioiritised each iteration and remain in ready for sprint. The rule we use as a team is once the card has three dots it needs to go back into the elaboration process and be prioritised as part of that process.
Massive thanks has to go to @clempickering for the initial idea. A thanks also to Steven Mendes for his help with this experiment.