This article addresses how to prevent common delivery issues, wasted time and rework at the team level when getting things done.

What problem we are trying to solve?

When delivering products and services, building software and cutting code, it is easy for the team to lose clarity and alignment on what needs to be done. This can be excasibated when the engineers are not the ones interfacing directly with the business or collecting requirements, and understanding can become diluted.

The output of the team can only be as good as the guidance given and we must be clear in intent and outcome of each piece of work requested.

If understanding diverges and the wrong work is marked as complete or is unfinished it can result in:

  • Delayed timelines
  • Unnecessary rework
  • Lacking correct & desired functionality
  • Frustration from the team

How do we give clarity?

To increase the chance of success and consistently deliver exactly what is needed to advance a product or service, the team can agree a non negotiable set of criteria which must be fulfilled by those requesting work be done. This provides all information required to begin work on the item. This criteria forms the Definition Of Ready.

In short the Definition Of Ready is a set of criteria that should capture all of the information required for any team member to pick up a task and accurately deliver what is expected, with a complete understanding of the outcome required from the outset.

The Definition Of Ready is split into two parts:

  1. Criteria defined by the requester
  2. Context agreed by the team

Disclaimer: We must be careful when introducing a bureaucracy, these rules or guidelines must promote ease of getting things done and not restrict them. All bureaucracy should be regularly reviewed to ensure it is still meaningful and relevant, including your Definition Of Ready.

Example Definition Of Ready

Criteria defined by the requester

  • The request has a clear title giving high level context of the required outcome in plain English.
  • The request has clear business context which notes the required outcome and value of the work.
  • The request can be traced to the requester and business need.
  • The request has a concise and meaningful user story.
  • The request has clear acceptance criteria written in the imperative.
  • Any required sign off has been given including legal, data protection, security etc.

Context agreed by the team

  • The team has estimated the work in their standard measure ie complexity / time / effort.
  • The team has clarity on how to complete / engineer the request.
  • The team has clarity on how to integrate the request to the existing product or services.
  • The team has clarity on how to test the work ie code unit, integration, regression testing.
  • The team has clarity on how to demo the request to the team, requester and wider audienance.

When is a request not ready to work on?

  • If the work estimate takes more than one sprint it is likely too large and should be broken down into individual units of work which can be completed either in parallel or as dependent work items.
  • If the team do not have consensus on what needs to be built, the lead or product owner must contact the requester and discover what is required.
  • If the requester keeps making amendments to the request. This is seen as uncertainty and whether the business requirement is clearly defined. This should be taken back to the requester for clarificiation.

How does this work in the real world?

Engineering teams often service requests that come in the form of tickets. Whether it be through a Service Desk, Post-It notes or information added to a Scrum/Kanban board, these tickets contain the context of the work that needs to be done. This is the interface for the requester to the team.

It is here that the Definition Of Ready is met.

The team review the tickets alongside those that facilitate the role of tech lead & product owner; note the activities of these roles may be shared as not every team has a dedicated product owner.

Within Scrum there is a ceremony where the team can give their input and meet the Definition Of Ready, this is refinement. After clarity has been achieved and the definition met everyone should be satisfied that a team member can pick up the ticket and complete the work, even if they have not seen it before. They should have all information and context needed to complete the work.

It is the responsibility of the requester, team and leads (product / tech) involved to ensure clarity and alignment is achieved. This is how we prevent misunderstandings and rework.

Additional benefits

Preventing Scope creap

Having a clear definition of what is required can help prevent scope creap - when tasks widen incorporating effort on areas outside of the original request. It is not a silver bullet but provides a path for an engineer to follow without getting lost and meandering, which can result in wasted time or irrelevant functionality being added as some developers find it interesting.

Planning

The lead or product owner are typically the people prioritising the work to be done. If the Definition Of Ready has been met, there should be a fair estimation of how long it is expected to take to complete and delivery an outcome; knowing this helps us prioritise how much work is reasonable for a team to complete. Burndown charts can be a menace and metrics are easy to manipulate to give the appearance of good management but it is more important to set the right expectation with the stakeholders of how long until their request can be completed alongside protecting the team from over work. Having a reasonable estimation can help this immesurably.

Revisions

Any significant changes to the original request before the work has begun should be taken back to the product owner and team lead to give a green light for continuation or cycling it in the backlog and prioritisation. Hopefully the original request includes all you need.

Wrap Up

There we have it. Align the team with the business and save headaches by agreeing a Definition of Ready. Prevent confusion, wasted effort and push back on fuzzy requests.