Agile-Enabled User Stories are Also Business Cases

As I stated here the agile-enabled user stories (AEUS) have to be business oriented. So any user story, when comparing it to the classic architectural layers of a system, is a column or better, a thread. A thread, that runs from the top to the bottom of a system. A business thread.

This led me to the conclusion, that in case of agile-enabled user stories we cannot just define an agile-enabled user story in the context of system's requirements only. These requirements that belong to the well-known four views on the IT architecture (functional, development, deployment and quality views) represent simply just one of the two AEUS definition dimensions. The first one is the requirement dimension that defines what should be build, and is a standard and known by everyone. However there is a second definition dimension named the business case dimension. This definition dimension consist of many subcategories, answering additional questions about an AEUS like why, how, who etc. Here a short list of these subcategories, based on a classic business case template I have found here www.bis.gov.uk/files/file42721.doc:

• Background - describe the agile-enabled user story.  Why it should be done now and what are the implications of not doing it.

• Scope - what the scope of the user story is, its key objectives, deliverables and purpose. 

• Objectives - what you want the user story to achieve when it has been completed. Your objectives should be SMART - specific, measurable, achievable, relevant and timely. Avoid words like improve, optimize, clarify, help etc. These are vague words that mean, you cannot estimate such AEUS and you cannot measure your result.

• Options - describe and evaluate the different options and give reasons why the preferred option was chosen, including the 'Do nothing' option.

• Proposed Solution - Identify the selected option and how you propose to implement the AEUS. 

• Benefits - Summarize the main benefits and how will they be realized. For an AEUS the focus lies in elimination of waste (lean).

• Risks - identify the key risks that might impact on the user story and the achievement of desired benefits. 

• Dependencies - are there any user stories that are either dependent on the outcome of this user story or that the user story will depend on.

• Affordability - What resource will be required, including staff resources and where will this resource come from?

• Analysis of costs - estimate the user story. You can use a method you like i.e. direct or proxy estimating.

• Critical success factors - outline the things that must go right to ensure the success of the user story. It can be combined with the risks section.

• Procurement procedures - explain your proposed procurement route (if applicable).

It seems the idea introduces an overhead, but I think it's even good and in some cases enough to keep this business case dimension just only in mind, when defining and planning the agile-enabled user stories. You will see how great the result will be… on time, in budget etc
---