(Note: For those of you who don’t know, Mr. Narendra Modi is the newly elected Prime Minister of India, and Modi Sarkar means ‘Modi’s government’)

After my last post elaborating scrum lessons learnt from a sporting event, I was on the lookout, wondering what comes next. This post combines another passion of mine – politics, with a particular concept related to Agile. The idea for this piece was formulated during a discussion with my project Architects – Manmohan and Romi. Without further ado, I will dive straight into the topic.

The area I am going to cover is User Stories and Acceptance Criteria. A common myth among newbie “Agile” followers is that documentation is obsolete in “Agile” practices. This is completely untrue, and while Agile says ‘working software’ is more important than documentation, it does not imply that documentation must be trashed (especially requirement documents). In an Agile environment, the focus is to make the documentation as lean as possible, i.e. document only what is necessary. To be nimbly Agile, we need to avoid spending time and energy on the futile task of writing lengthy, complicated and at times boring documentation.

This is where the idea of User Stories and Acceptance Criteria comes in, to ensure your requirements are defined in a simplified manner. User Stories are an excellent method to describe your requirements in simple sentences, which are then validated using relevant Acceptance Criteria. The key to having a good User Story is the ability to convey the requirement in simple sentences that outlines – who the user is (or role impacted by that requirement); what they require; and to achieve what. Basically, it states what the user is expecting when you fulfil that requirement. To supplement a good User Story, the Acceptance Criteria has to be well thought out and precise. While User Stories are comparatively easier to define, the hallmark of a good Acceptance Criteria is that it should be quantifiable and testable. This is the best way to ascertain if the achievement of the User Story can be measured. This also makes life easier for the testing folks, who now have precise information, with tangible results to evaluate.

I know most of you are already wondering what this has to do with Mr. Modi, and the government of India. Now, imagine you had an opportunity to help our Prime Minister define the User Stories for his government. That is, imagine that as citizens of this country we could use Acceptance Criteria to determine the outcome of the next elections.

Let’s take a shot at trying to define a User Story and Acceptance Criteria that would help Mr. Modi to implement some of the priority areas he addressed in his manifesto (his product backlog :)) during his election campaign:

As the PM, I would like to implement financial policies that would contribute to economic growth.

In a simple sentence we have defined what the requirement would be for a top priority area like financial and economic growth. Here the user is PM (the role) and he wishes to implement financial policies (the requirement) to achieve economic growth (what to fulfil). This is a very simplistic example of a User Story.

Now, the above example has to be supplemented with Acceptance Criteria which would help identify if the requirement is fulfilled. For this we will look at two options:

As the PM, I would like to implement financial policies that would contribute to economic growth.

Acceptance Criteria Set 1:

1. Reduce inflation and increase GDP
2. Make Rupee stronger against the US Dollar

As the PM, I would like to implement financial policies that would contribute to economic growth.

Acceptance Criteria Set 2:

1. Reduce inflation to 5% and increase GDP to 9% by the end of 48 months.
2. Strengthen Rupee against US Dollar to Rs. 38/USD by the end of 48 months.

Which of the above sets of Acceptance Criteria is relevant for the User Story mentioned in the example? Set 1 or Set 2?

It’s a no-brainer that Set 2 provides more tangible and measurable options, by which we can verify if the requirement is actually fulfilled. Here, the Acceptance Criteria in the second instance would provide precise evaluation, while the first instance would only give an ambiguous picture, relying heavily on perception. My experience has always indicated that in many instances software development is treated as rocket science, whereas a more pragmatic approach would make it simpler. A good, well defined User Story, combined with testable Acceptance Criteria would go a long way to achieving it.

While I agree that my example of using the new government is very simplistic in nature, I would love to hear the reader’s views on the following:

1. What are the most common challenges that you or your team faces while defining or understanding a User Story?
2. Take a shot at defining a User Story for our government, with what you feel could be achievable Acceptance Criteria, based on your expectations.

Please comment and feel free to disagree with me while we continue on our journey of being truly Agile.

Image Credit: Jacopo Romei on Flickr