Toggle Menu

Insights / Agile Transformation / How Do We Know We’re Ready to Start Development?

August 25, 2016

How Do We Know We’re Ready to Start Development?

2 mins read

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.

  1. Wireframes and content – we needed stakeholder-approved design and content.
  2. 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.
  3. 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

Resources

Simplifying Tech Complexities and Cultivating Tech Talent with Dustin Gaspard

Technical Program Manager, Dustin Gaspard, join host Javier Guerra, of The TechHuman Experience to discuss the transformative...

Resources

How Federal Agencies Can Deliver Better Digital Experiences Using UX and Human-Centered Design

Excella UX/UI Xpert, Thelma Van, join host John Gilroy of Federal Tech Podcast to discuss...