In order to maximise the efficiency of the sprint planning meetings it is important to frequently review the list of Not Done Product backlog Items (PBIs) and, where required and / or possible, add clarity to the information. This process is called Grooming the Backlog and should be done by the Product Owner and team together. During grooming the PBIs will be moved from ‘Not Done’ to ‘Ready’. During the sprint planning meeting we restrict ourselves to only choosing PBIs that are 'Ready' for development.
Roughly 5-10% of the time on the project should be spent grooming the backlog. This can be done by anyone at any time, but often it is worthwhile booking meeting time to do it explicitly if the project requires it (an experienced Product Owner who actively grooms the backlog themselves may negate this need). Note that not all of the backlog should be groomed, in fact it is just as important to not over groom the backlog – spending too much time refining requirements for distant sprints increases the risk that these requirements will change in the meantime.
Each project may create its own definition of ‘Ready’, however a suggested minimum is as follows:
- Each PBI should be worded as a function with business value and with a clear ending – e.g. ‘As an applicant I can create a resume online using a template so that my resume looks professional’ rather than ‘As an applicant I can manage my resume’ (too vague)
- Each PBI should have conditions of acceptance defined indicating how it will be tested. This should include negative tests – e.g. phone number must contain digits only
- Each PBI should include ‘non functional’ details such as user permissions, logging, performance requirements
- Each PBI should have an estimate in story points, assigned by the development team (devs + BAs + Testers) using planning poker techniques
- Each PBI should be small enough to comfortably fit in a sprint. Each project may decide on a cut-off for story point estimates – e.g. anything greater than say 8 needs to be broken down further before being considered ‘Ready’
- If applicable, each PBI may provide lo-fi mock ups / diagrams / brief documentation of the anticipated functionality. However avoid too much design work up front.
- Both the Product Owner and team must agree that the PBI is ready
