Preparation is “everything” … well, sure not really everything but well prepared user stories do make the sprint much less painfull. As a scrum master I insist on only having ready stories in the sprint planning. On I found a nice article by Ian Mitchell on that topic. Here are my personal key take aways …


Product Backlog refinement ought to de-risk Sprint Planning. Enough refinement will therefore have been done when a team can plan it into in their Sprint Backlog as part of their achievable forecast of work. The acid test of that condition can be brutally simple. If work has been refined to the point that a team can estimate it, and it is thought small enough to be planned into a Sprint without being broken down further, then that might well be enough.
A team can up their game by asserting further conditions which must be met before work is considered ready for planning. It is reasonable, for example, to expect acceptance criteria to be articulated for a backlog item such as a user story. Without such criteria developers may not really understand the scope of the work or how it will be tested and validated. In fact, it can be hard for developers to truly estimate work at all unless the acceptance criteria are defined. That’s where the meat often is. They may also reasonably expect clear value to be associated with the item, and for this to be expressed in a succinct way which makes it quite evident. The standard user story format of “As a <type of user>, I want <some goal> so that <some reason>” is helpful and a team may reasonably expect something along these lines. They may further expect each item to be actionable in its own right and free of dependencies. Additionally, they may expect enough flex in the item to allow for experimentation in finding the best way to implement it.


One of my favourites while working with teams to prepare user stories is the INVEST principle that Ian also mentions in his article:

(Independent). The PBI should be self-contained and it should be possible to bring it into progress without a dependency upon another PBI or an external resource.

(Negotiable). A good PBI should leave room for discussion regarding its optimal implementation.

(Valuable). The value a PBI delivers to stakeholders should be clear.

(Estimable). A PBI must have a size relative to other PBIs.

(Small). PBIs should be small enough to estimate with reasonable accuracy and to plan into a time-box such as a Sprint.

(Testable). Each PBI should have clear acceptance criteria which allow its satisfaction to be tested.

Source: “Walking Through a Definition of Ready

This blog is a digital memory for me. I store nuggets of information, ideas and resources on these pages so that I can access and share them easily at any time, from everywhere. I always felt a strong passion for continuous improvement and that is why I am now super happy to be a professional Scrum Master. Scrum, Kanban, Agile Project Management, Coaching, Learning and Self Management are my passions and that is also what my blog is about ...

Leave a Reply