Agile Practices for Increasing Requirements Quality

Commitment QualityMy book What drives Quality: available on  Amazon  Leanpub  webshop  Other stores

To deliver high-quality products to customers, agile quality practices have to engrained throughout development. It all starts with ensuring the quality of the requirements.

There are several factors that influence the quality of requirements and thus drive the quality of the software that is being delivered to customers. In this blog, I will discuss two of them in detail: Commitment and Stability. I will also describe agile practices that can be used to work with requirements in an effective way and increasing the quality.


The purpose of requirement commitment is:

to have agreements between the stakeholders and project manager about delivering a product with specific functionality by a project/team to their customers.

Having commitment on the requirements by all involved stakeholders is important as it ensures that you are developing a product that your customers need and are willing to pay for. The project/team also needs to be committed to do whatever they can to deliver the product with the specified functionality.

You don’t need to have commitment on everything when you start a project. It is unfeasible, too expensive and takes too long to get. To support that teams can start developing a product, make sure that the stakeholders agree on the priority: What needs to be delivered first, what do we need now? That should give sufficient commitment to warrant investing time and money.

Agile teams use product backlogs to manage their requirements. Product owners prioritize the user stories. To enable delivering products with sufficient quality agile teams need to have user stories that are ready at the start of a sprint.

Teams can use a Definition of Ready (DoR) to check the user stories. A DoR states the criteria that a user story should meet be accepted into an iteration.

Some useful resources to make your own Definition of Ready are:

Having prioritized user stories ready at the start of an iteration helps to increase commitment from the stakeholders and the development team, resulting in higher product quality.


Requirements Stability is the inverse of the amount of requirement changes over time.

The fewer requirement changes you have, the higher requirements stability will be.

The aim of requirements stability is not to prevent changes to requirements from happening. They will happen. Discouraging them or (even worse) ignoring them is no solution. What matters is that projects and teams are sufficiently capable to deal with changes and can maintain stability during development.

Agile teams treat requirements as stable during an iteration. When a user story is added to an iteration the assumption is that there is a real need for software that fulfills the requirement. In agile projects, the requirements are fixed during an iteration and flexible during the project (more on this in fixing scope in agile projects). Time and money is invested with an iteration, every decision on adding a user story to the iteration backlog of a team is actually an investment decision.

If there is a risk that a requirement underlying a user story can change on a short notice then it could be better to select another high priority user story for the next iteration. It’s a good practice to always have user stories ready for 2-3 iterations so that it is possible to switch user stories during the planning game. Which also helps if a team is able to finish all user stories before the end of an iteration, at that time they can discuss with the product owner to pick another high priority user story and add it to the ongoing iteration.

Iterations can also be used to clarify a requirement. You can use a spike story, a practice from eXtreme Programming, to research a requirement or to investigate the feasibility of a technical solution which helps you to drive out risk and uncertainty. This is similar to using a Minimum Viable Product in Lean Startup to increase the knowledge of what customers really need.

Increasing requirements quality with agile

To be able to act upon changing requirements a good approach is to commit as little as possible. Olav Maassen and Chris Matts suggest in their book Commitment to “never commit early unless you know why”. I think this is a good approach to deal with change.

Commitment and stability support each other, by committing only what needs to be done in the next iteration the stability of requirements increases, resulting in high-quality products to be delivered to customers.

What Drives Quality

The book What Drives Quality helps you to prevent software problems from happening by building a shared understanding what drives software quality. It enables you to effectively take actions, saving time and money! This blog has been included this book.

(This post was updated on November 8, 2017: My 2nd book What Drives Quality is released).

  • 35

Ben Linders

I help organizations with effective software development and management practices. Active member of several networks on Agile, Lean and Quality, and a frequent speaker and writer.

This Post Has 2 Comments

  1. David Koontz

    Wonderful view point on increasing quality via adding energy into the system early (rather than late – e.g. testing quality into the product). Thanks for the additional resources… if I may add to your list… I’ve found that many teams struggle with creating a DoR & DoD therefore I’ve created a set of index cards to help start the discussion of the attributes of a Definition or Ready/Done. Not that these are the correct attributes, but I’ve found that they prime the pump, start the dialogue, and result in a shared understand of the teams artifacts.

    You can find the PDFs here:

    I wonder how to tune the system to the right amount of Stability? I expect that viewing the DoR as a living document that must change & mature with the team and the product lifecycle is a start to tuning the requirements stability to an optimum point. What else could we do to encourage this?

    1. BenLinders

      Thanks David for your comment. Your cards and the supporting blog can certainly be useful for team to define their DoR and DoD. If added them to the list of resources.

      The list of resources mentioned above aims to help teams to define their own DoR. As your blog mentions:

      “It is not the artifact – the list of done criteria, that is important for your team – it is the act of doing it for themselves, it is that shared understanding of having a debate over some of the gray areas that create a true working agreement.”

      A DoR defines how the team works together with the product owner. Agile Retrospectives can be used by teams to reflect and update the DoR where needed.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.