We continually hear about project disasters, cancellations, overruns or over spends. Are requirements really to blame? If they are, can we fix it? Does Agile have a part to play in this?
From the Planit Index for 2011 the following information, gathered from some of the major organisations within Australia and New Zealand, seems to suggest that requirements are perceived to have a major contribution to project failure. While only a small number of projects were actually cancelled – just above 4% – some interesting findings can be derived from investigation of the reasons why these projects failed.
The number one reason for failure was that business requirements or priorities had changed. This aligns with the findings that almost 30% of projects suffered changes to 25% of their scope or more. While organisations have to be flexible to contend with changing conditions, these results point to a weakness in the overall definition of requirements in projects. It is also likely that this issue, with changing business requirements, may also be responsible for many of the projects that fail to achieve satisfactory outcomes due to time and cost overruns.
Figure 1 - Causes of Project Failures
When asked the question “How would you generally rate the conditions for your software development projects?” the following responses were received.
If the high rate of project failure reported, only 49% of projects were reported to be delivered on time, within budget and to scope, is directly related to the implementation of quality assurance practices, then the examination of project conditions reveals that there are numerous reasons why quality assurance is not conducted in an optimal manner.
Further causes of turmoil in projects included unrealistic expectations, which were cited by 31% of respondents. Once again these results point to the problems that many organisations are experiencing when scoping requirements at the early stage of project development.
Figure 2 : Rating of Project Conditions
The Agile Manifesto refers to requirements in at least three of its four statements. “Working software over comprehensive documentation” – does that mean the working software in effect becomes our requirements? Does it also imply that hundred page requirement documents are not the best way to capture requirements for the whole team to understand?
“Customer collaboration over contract negotiation” – does this reflect that the best way to elicit requirements is through continuously talking with our clients as things change, not just when the contract says we can, or mandate that a particular item must be delivered at a certain time even if the priority or use changes? Linked with this is “Responding to change over following a plan” – who is to say that our initial thoughts were 100% correct or that we had considered everything? We cannot possibly know everything up front. What happens if our competitors release a product we don’t have and we start losing market share?
Even some of the 12 Principles of Agile Methods refer to requirements. For example:
- #2: Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
- #11: The best architectures, requirements, and designs emerge from self-organising teams.
As we have already discussed change is embraced within Agile. Shouldn’t we in IT align to the business strategy and be there to partner as support to the business initiatives not to hinder them. IT needs to increase its capability and have the same goals as the business.
Secondly IT, based on sound technical knowledge, should strive to create the best solution for their customers. If requirements are heavily prescriptive and “cast in stone” it stifles creativity. Working proactively with the business throughout the delivery allows fluidity and adaption to moving priorities. It also allows the business to focus on requirements in small groups close to the release, which allows for flexibility to evolve in a different direction as more becomes known about a subject. It can also restrict the “nice to have” syndrome, as the business sees some product and then want to move to the next without necessarily putting on all the “bells and whistles”. They know they are going to get what they want within agreed iterations and therefore move away from the mentality of “I have to get everything in as I do not know when I will next get an opportunity”.
One of the most significant changes that occurred with the introduction of Agile software development methods was how these methods captured requirements.
The foundations on which traditional requirements management processes are based still apply with an Agile approach. The techniques for gathering requirements remain unchanged regardless of whether you are in a waterfall project or an Agile one. The key difference is at what point you apply the techniques in the software development process. Agile methods recognise the major failing with the traditional requirements processes of trying to define all the requirements upfront.
Agile methods therefore, focus on simply capturing – at a high level – what are needed i.e. high level statements and descriptions. Requirements in an Agile process are now “place holders for conversations that need to happen at a later date”. The “later date” is when the requirement is scheduled in the iteration. The requirements process is carried out using a “just-in-time” approach. This avoids wasting time to write documentation which may change later.
The Planit Index asked the question – “How would you rate your requirements definition?”
We have already seen the impact that poor requirements scoping can have on project outcomes, but how did respondents rate their organisation’s requirements definition? In Figure 3, a third of respondents indicated that their organisation’s requirements definition was either poor or very poor, and another third rated them as only OK. Worsening results were experienced at both extremities of the rating scale when compared to the 2010 Index, with a 2% decrease in the number of respondents who rated their organisation’s requirement definition as excellent and 4% increase in negative responses.
This unfortunately is pointing towards a trend that we within IT are getting worse at writing requirements which are of value to the business, or maybe even testable.
Figure 3 : Rating of Requirements Definition
Within Agile, details about the requirements are fleshed out using face-to-face based communication techniques, primarily workshops, with the project team and the customer. The teams have a better understanding of requirements on Agile projects due to this process. How can we think that handing over a 100 page document of requirements to the team with little further communication is likely to produce success?
The outcome is “lightly” documented, i.e. sufficient information is captured to enable:
- Estimates to be made on how long it will take to implement, which include all activities which the team can then commit to
- A common understanding of what the user actually wants
- Clarification of what the acceptance criteria will be for the requirement ensuring that everyone is focused on testing and building quality in
User stories have become the de facto approach for capturing the user’s requirements in agile based methodologies. Mike Cohn in “User Stories Applied” provides more detail on what type of information a user story actually contains and is described below.
A user story is composed of the following three aspects:
- A written description of the story used for planning and as a reminder
- Conversations about the story that serve to flesh out the details of the story
- Tests that convey and document details and that can be used to determine when a story is complete
User Stories Applied: For Agile Software Development – Mike Cohn 2004
Writing User Stories
Grasping the concept of what a user story is may be straight forward, but writing them does have its challenges. The common challenges faced are:
- How much detail should the story contain
- The story is too large (generally called an epic) and needs to be broken down into smaller pieces (sounds easy, but it isn’t)
- How to capture the business rules applicable to a user story, i.e. should the business rules be captured as additional detail on the user story or captured as acceptance criteria/conditions
- How to make user stories independent
I have found that breaking stories into different persona to which the story applies to be helpful and also splitting stories by artefacts for example if you are looking at loans, each different type could be a story. This will also help with prioritisation and putting stories into different iterations i.e. if 70% of your clients use a particular loan type, do that one first. It will also unlock you maximum business value and return on investment.
When writing a user story, focus on the following aspects:
- Who is the story about
- What is it they want to do with the system
- Why do they want to do this action
Whilst the amount of detail in a user story may be less, associated with each story are the acceptance criteria. This means that from the conception of the requirement the team is thinking about how to test it i.e., building testability in. Extending this further the team should also be thinking about how they can use automation to test and therefore building the hooks in. This coupled with the greater collaboration and discussion about the story should ensure the requirement is of high quality and delivers maximum business value close to its elicitation. Changing requirements, which is also cited as a major contributor to project fail, can also be improved within Agile. Agile embraces change, if you decide halfway through a project that a lower value item is no longer required – why build it just because it is in the backlog? If a story increases in value or a new requirement will provide the business with greater value than what is still left in the backlog then let’s do it. Due to the close working relationships discussions can be had about the impact of this from both the product risk perspective and the technical implications. Both parties are in fact partners in delivering the common goal of business value as quickly as possible.
Agile methodologies should therefore make significant improvements for projects in the area of overall requirements management and delivery. That is not to say that it can’t also make improvements in other areas too, such as estimation which is easier on smaller chunks of functionality. When putting into place these Agile practices for requirements management we can really see the benefits.
Planit then asked the question – “To what extent would your business benefit from improving how requirements are defined?”
The problems experienced with requirements definition was further reinforced by the 98% of respondents who agreed that improving requirements definition would deliver a benefit to the business (Figure 4). It can be reasonably assumed that investing greater time and resources into this activity will lead to better outcomes by correcting a factor which is seen as a key contributor to project failure. These however needs to be focussed at the right time within the project i.e. as the requirements are elaborated with all the team involved to ensure they all have the same viewpoint and not midway through when we all know that adding more resources does not necessarily help.
Greater Business collaboration and ‘just in time’ writing of requirements can only help in this area.
Figure 4 : Benefits from Improving Requirements Definition
It can be seen from the Planit Index that more companies are adopting Agile in software development as the percentage increases year on year. This is not to say that Agile is the “silver bullet” however there is a lot to say about how using these practices can improve requirements and the strength of the cross IT/business collaboration.
Figure 5 : Methodologies
There is also further evidence from the Planit Index that when Agile is adopted projects are at least generally more successful 56% of the time. As requirements appear to be such an issue in traditional projects this evidence seems to suggest that some improvements are made in the requirements process, as well as possibly in other areas.
Figure 6 : Agile Success
In conclusion it seems that many projects do suffer from poor requirements elicitation, documentation and management. Traditional projects are not set-up to deal well with change, particularly nearing the end of testing. Many have high process around change request management which actively discourages any change. The business has had intensive involvement during the initial phases of the project but they do not again become engaged until near the end for UAT. If this is a large program of work it may be a year later, by which time their business and processes may have moved forward to satisfy the needs of their customers. Often it is then too late to make changes before the next release to production.
Agile on the other hand continuously engages the business, collaborates with them on the next set of functionality and encourages review, update and reprioritisation of requirements. The business is involved within the iteration, providing on-going feedback to ensure that the product meets their needs, elaborating on the requirements just before they are worked on and then released. They are showcased the product as soon as it is considered done, or even earlier if prototypes are used. Product grooming allows the business the opportunity to reprioritise and even introduce changes as they happen. Finally with frequent releases to production the end users are enabled to provide quick feedback which can be incorporated into the backlog.
Agile allows for requirements to be worked on as they are about to be delivered saving waste; allowing for change and reprioritisation as the project proceeds; and frequent feedback loops, leading to business satisfaction and unlocking value quicker.
Please refer to the 2011 Planit Testing Index Executive Summary for more details.