How Do We Know We’re Ready to Start Development?
Teams want to jump straight to execution on a new project, but then spend several sprints spinning over what is actually needed. Creating a Definition of Ready (DoR) will help your team know when they are ready to start development. What is a Definition of Ready? Team Agreement – it is an agreement made by […]
Teams want to jump straight to execution on a new project, but then spend several sprints spinning over what is actually needed. Creating a Definition of Ready (DoR) will help your team know when they are ready to start development.
What is a Definition of Ready?
Team Agreement – it is an agreement made by the team to determine when a product backlog item (PBI) is ready for execution. It is not determined by stakeholders, executives, or project managers.
Objective, Measurable, Specific – the DoR should capture information which helps the team determine if a PBI is objective, measurable, and specific enough to execute.
Just Enough – the DoR should include the minimum amount needed for the team to execute a PBI. The team should revisit this in retrospectives to revise and update as needed.
Most importantly, the team should never begin work if it doesn’t meet their DoR.
Applying It to a Team
My client’s project kicked off with a brand new team comprised of myself as the ScrumMaster, the clients as Product Owner and Subject Matter Experts, and a vendor team as Business Analysts and Developers. The team prepared a backlog, discussed requirements, and kicked off release planning.
Then, we spent 3 sprints hashing out details and delivered nothing.
What Went Wrong?
We spent the majority of our sprints in meetings and getting questions answered. The little work which was completed needed re-work as we discovered more details.
How Did We Fix It?
As a team, we brainstormed what we needed to start development. We used our experiences, and we agreed to hold ourselves to this definition. We identified three specific items.
- Wireframes and content – we needed stakeholder-approved design and content.
- Business logic – this was a financial system with many “What If” options. We held Q&A for each section prior to sprint planning to uncover details.
- System dependency – this tool integrated with many systems. We identified dependencies in advance of a sprint and discussed options with the system owners.
Once we established this Definition of Ready, the team mindset improved. The team was more open and less defensive. We had fewer meetings and delivered more functionality at the completion of each sprint.
What have you included in your Definition of Ready?
Interested in learning more about Agile Requirements? Join us on September 28 for an Agile Requirements Workshop in Arlington, VA.
You Might Also Like
Getting Agile requirements right can be a challenge but it’s essential as they can make...
Scaling, like Agile itself, can become a target objective rather than the means to an...