What is your definition of "ready"? (for a PBI)
Hi,
I have read somewhere that a scrum master shouldn't let a product owner enter a sprint planning meeting with a product backlog that is not ready.
I don't know what the scrum master is supposed to do. Cancel the sprint planning and waits for a ready product backlog? When I met this kind of issue and I used the sprint planning timebox to groom the product backlog. And you what do you do in that case?
Whatever, my question is what is your definition of "ready" for a PBI? "Ready" in that it can be selected during the sprint planning meeting?
What do you think about this for mobile application development:
- Screen mock drawn
- Accetance tests written
- Use case updated
Do you think, it is enough? Or too granulate?
Florent
Of course we should add : " - SMART user story written and estimated" to the definition of "ready"
Hi,
I like to use the INVEST criteria as a guideline.
http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/
I like to bring this up in the retrospective (perhaps have a retro focussing on this point).
I also reinforce the need to spend 10% effort reviewing and maintaining the backlog to prevent this recurring.
For mobile development I have found having wireframes essential, and depending on the composition of the Dev team, the specific assets required as well.
The acceptance tests get written in the Sprint - and I encourage the use of Gherkin syntax to specify acceptance criteria http://docs.behat.org/guides/1.gherkin.html
The team will tell you if you go too granular, and the timeboxing of the work maintaining the backlog will prevent you slipping in to task breakdown.
The Scrum Master doesn't have the authority to cancel Sprint Planning, but does have a duty to make sure that Sprint Planning is facilitated, and that all parties have been coached properly in accordance with their responsibilities.
If a Product Backlog isn't ready for Sprint Planning, it means that the Development Team will be unable to make a forecast (i.e. they won't be able to create a Sprint Backlog), nor will they be able to commit to making an incremental delivery of value.
The Scrum Master needs to coach the team and the Product Owner on how to groom a Product Backlog so Sprint Planning can proceed without impediment. Remember, the Scrum Master has a duty to ensure that this happens before Sprint Planning even starts.
According to me product owner should provide stories or features which team can pick up and work in a given sprint. Product Owner should be ready with small vertical slices of a feature which team can pick up and do. In mobile application development there would be definite need for UI definition so layout or mockup would definitely help team understand feature better. Use cases are must. As part of backlog grooming meeting team and PO have to work in refining use cases every day. PO (Product Owner) should be well prepared with list of use cases before planning session and team should have good idea on what is going to be there in coming 2 sprints atleast.
If backlog grooming every day post scrum for 15 to 30 min then it would help PO to refine backlog and helps team by saving time spent in sprint planning.