To deliver high quaility product 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 warrent 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:
- The INVEST principle by Bill Wake
- 10 Tips for writing goog user stories by Roman Pichler
- The book User Stories Applied by Mike Cohn
- The book 50 quick ideas to improve your user stories by Gojko Adzic
- Using a Definition of Ready on InfoQ
- Exercise cards for definining your DoR and DoD by David Koontz
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 less 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 interation 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 higher quality product to be delivered to customers.
The book What Drives Quality helps you to prevent software problems from happening by building an shared understanding what drives software quality. It enables you to effectively take actions, saving time and money! This blog will be included in a next draft of this book. If you want to read the book and review it, please contact me.