From Requirements to an Agile Backlog

As an Agile coach relatively new to working within the federal space, a recurring issue has been the lack of shared understanding about a basic Agile/Scrum concept – the backlog.

In many of the governmental Agile projects – and yes there is considerable debate on what are the minimum Agile values / practices / principles that need to be in place before a project can be considered, but for now I’m referencing any project that is self-identified as Agile – the lack of a viable backlog is the biggest project risk.

And many of the Agile practices and principles are rooted in risk management. Surfacing assumptions as we do in Agile projects is risk identification. Validated learning, which is at the heart of both demos and retrospectives, is active risk mitigation and so forth.

So, let’s go back to the basics and establish what is and isn’t a backlog.

What a backlog isn’t:

* A wish list of everything and anything even tangentially related to the domain

* A list of “requirements” generated years before that have been “converted” to user story format

* A list of everything that the legacy system did, often captured in multiple excel files, with the most frequent comment being, “functionality to match or exceed legacy”

What a backlog is:

* User stories that have been written to support the project vision and to deliver the minimum viable product at least

* User stories that are complete, i.e. with acceptance criteria and supporting artifacts for design and architecture so that development teams can begin work on day 1 of a sprint

* User stories that have been prioritized by the product owner and estimated by development team and so on

Too often, an Agile project begins with training oriented towards building teams and you’re told that the backlog has already been developed. And then you, as the Agile person, look at their “backlog”, wonder how the project got off-track this quickly and begin the necessary discussions to reset.

So how do we arrive at this scenario? Let’s walk through some probabilities…

The decision to go Agile for many projects seems to happen as the development phase is scheduled to begin. Which means that usually the requirements and design phases have already been completed for this project since most government environments are rooted in waterfall.

And the people responsible for the original requirements output were highly unlikely to be Agile practioners.

The requirements gathering process most probably focused on exhaustive coverage of everything anybody has ever considered, instead of targeted coverage of high-value functionality. The orientation would have been on “What” and maybe “How” to the exclusion of “Why”. The “What” and the “How” would have been based on the users’ knowledge and comfort level, usually the existing application.

Then when the decision is made to “go Agile”, the requirements from the specifications document were converted to user story format, often with several requirements being combined into one story, and called a backlog.

This results in substantial sunk cost which is then used to weigh every subsequent requirements management decision. Clients, who have already paid significantly to have output generated don’t want to pay someone else to “redo” the same process until the risks of not having a viable backlog are revealed.

The next post – on Tuesday – will detail one process that has been developed to address this scenario. Basically how do you go from this so-called “backlog” to a true Agile backlog that can be the backbone for value delivery?


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s