Story Definition of Ready
Apr-2019
As a helper in the development process of proponent of Agile within development teams, I have often noticed that a lot of effort is spent in defining work that helps the “customer” or the product owner to hold the development team accountable for the work in question. I do not see much attention paid to the other side of the coin.
When is a story ready to be worked on? What are the criteria for success of the development team. Not what they need TO DO in order to succeed. What they NEED in order to succeed.
I am presently working on a project where this is more than apparent. We are working on a nebulous conversion project, with a myriad of technical issues and frankly one that has challenged me often both technically and in Agile. I personally missed the opportunity to define Story Definition of Ready for our teams. I wish I had not made that mistake.
In my opinion, here are the items required to ensure success of the teams in delivering their stories. YMMV
- Clearly defined business value in the story verbiage
- Defined any specs required to be adhered to
- Clearly defined external dependencies and acceptance of risks, ideally have NO external dependencies
- Story Acceptance Criterion Defined
- All Data and other technology required for Story Acceptance defined and available
A good user story should be: (I can never say this often enough!)
- “I” ndependent
- “N” egotiable
- “V” aluable
- “E” stimable
- “S” mall
- “T” estable
Don’t make the same mistake I made, go Define your Ready!