Agile Development – the Truth, the Whole Truth, and Nothing but the Truth

Share on FacebookTweet about this on TwitterShare on LinkedInGoogle+

Share on FacebookTweet about this on TwitterShare on LinkedInGoogle+

A common challenge encountered by organizations attempting to adopt Agile is Requirements Management. Different development methodologies have their own approaches to tracking project requirements and ensuring the development team produces a desired product for the customer. The path from concept to completion may take different routes per the type of project or the chosen methodology of the team, but regardless, it critical to have some form of requirements as a point of shared understanding and agreement between the team and the customer. This allows the project to not only proceed as desired, but serve as a point of reference for disagreements over the software as it comes to life, a standard by which to test against, and a starting point for any changes in direction that may occur during the project.

segue-blog-agile-the-truth

 

Traditional Requirements Approach

In traditional BRUF (Big Requirements Up Front) or Waterfall development, the project team creates a monolithic requirements document, often called a Software Requirements Specification (SRS) or Software Requirements Definition (SRD), before development work begins; and will update that document as change occurs during the rest of the development lifecycle. The requirements document always represents “the Truth, the Whole Truth, and Nothing But the Truth” for the software system. If the requirements document says something, you can count on it to be true – and if the software doesn’t work as described in the SRS, it’s a bug. If there is a change in what the software needs to do, it’s a change request – which must then be reflected by updating the requirements document by creating or modifying any number of individual requirements.

How Does Agile Account for Requirements?

In Agile development, we use User Stories instead of a monolithic requirements document. User stories represent a request to change the current state of the system, and once “Done”, should be discarded. A user story is considered “Done” when it meets all the criteria the development team has set in their Definition of Done. Typically, “Done” includes some variant of “the user story has been implemented, tested, and accepted by the Product Owner.” If the software doesn’t work as described… well, once a User Story is Done it’s Done, and there’s no such thing as “doesn’t work as described.” Instead, everything is “doesn’t work as desired,” and results in a new User Story reflecting the desired change.

The Agile User Story approach to requirements is all well and good for product-based teams with full ownership of the project, but for service-based teams building software on contract for a customer, things can get much trickier. Often, when a customer is looking at a software release, either for Acceptance testing or in Production, seeing something that doesn’t match their expectations may send them searching for some sort of requirements document or specification to see “is this what we agreed on.” This is particularly important when it comes to determining whether the customer will have to pay for the “correction” or not. With User Stories, which the Scrum Alliance describes asnot a highly documented series of requirements but rather a reminder to collaborate about the topic of the user story” it can be very difficult to get a full picture of the Truth, the Whole Truth, and Nothing But the Truth – you have to gather up all the User Stories affecting a particular feature and rebuild that picture of Truth.

Common Ground – User stories for Service-based projects

Getting customers on board with the Agile way of doing things can be difficult, particularly when those customers are not tech-savvy or have no experience with software development projects. For those customers, it’s important to be able to look back to some kind of requirements document and know “this is the agreed-upon Truth.” To further complicate matters, when the customer is the Government there may be laws, regulations, policies, or contractual terms which require creation of a formal requirements document.

In these scenarios, it can be helpful to have a way to transform User Stories into a requirements document, and ensure the requirements document stays up to date as the project evolves. When starting a new project, the User Stories and the Requirements Document will be similar in terms of content, although the structure may differ. As user stories are refined before implementation, the requirements document should be updated to reflect that refinement. Once a user story is “Done” it can be closed and forgotten about (or even destroyed, if you are keeping User Stories on index cards or post-it notes). When a new User Story is created, whether to add a new feature or change an existing feature, the Requirements Document should be updated to reflect the change. In this manner, at any time during the development lifecycle, you can look at something which reflects the Truth, the Whole Truth, and Nothing But the Truth, while still having the flexibility and collaborative aspects of User Stories.

Keeping User Stories and a Requirements Document in sync is extra work, but that should pay off in the long run as you can ensure that everyone, including the customer, is working from the same definition of Truth.

Download our Agile eBook