This is a nice, simple explanation of the basics of Agile project management a software engineering environment written by Adam Feldman. For the original article please visit his Project management blog

Stories. Acceptance Criteria. Value based prioritisation. Iterate often. Change is normal – be agile.

Stories

Agile encourages the use of User Stories as a requirements gathering technique.  Stories are similar to high level requirements, however, they are normally written from the perspective of the actual user.

It is helpful for each story to express the value of the story to the customer.  For example, in a Call Centre application;

“As a Team Leader, I need to see live call volumes, so I can manage my workforce”

“As a Call Centre Agent, I need to see all previous purchases, so I can cross sell and make more sales.”

“As a Call Centre Agent, I need to tell when my boss is coming, so I can stop surfing the net.”

Stories are simple, great if they are actually written by the customer, non-technical and brief.

Acceptance Criteria

So after the customer helps in writing the story – we should define the acceptance criteria.  This should explain what the user will be looking for to make sure the story has actually been done.  This will really help out the developer when building the story as it will remove ambiguity and assumptions.

So lets look at the first example from above – “As a Team Leader, I need to see live call volumes, so I can manage my workforce”.  The Acceptance Criteria should be brief and in the language of the business.  So appropriate acceptance criteria might be;

“I can see the number of calls in the queue from the dashboard.”

“I can see the average wait time in the queue from the dashboard.  Calculated as (total wait time / number of calls in queue).”

“I can see the number of calls taken in the last hour from the dashboard.”

“I can see the % of abandoned calls in the last hour from the dashboard.”

Value based prioritisation

Associating a value with each story helps us prioritise.  In Agile we need to completely involve the customer in the prioritisation process.  Having the customer express the business value for each story ensures they really thinking about the story and not just include it “because this is the way we have always done it”.

Where it makes technical sense, the Development Team will build the most important stories first, therefore, if they are unable to develop all of the stories in the release, it is the ones of least value to the business that are left.

Iterate Often

Rather than going for the big bang approach, Agile suggests breaking the Release up into multiple Iterations. An Iteration is a fixed time box and usually lasts anywhere from 2-8 weeks, the output is some form of “working software”, even if it is in the most basic form.  Sometimes these are called Sprints.

At the end of each Iteration, the project team will sit with the business and review the software. It does not matter how well you document the requirements, how nice your mock-ups are or how well you articulate something – there is nothing the same as actually sitting the customer down in front of working software and seeing what they think about it.

Another benefit of multiple, short iterations is that it really gives the team a chance to take stock and gauge how they are tracking.  It is pretty obvious things are not going to plan if at the end of the first iteration you have 3 stories that are incomplete!

Change is normal – be agile.

So let’s take the example from above, the first iteration may have simply been to build the story “As a Team Leader, I need to see live call volumes, so I can manage my workforce”.  At the end of the first iteration, the customer can be shown through what has been built and has a chance to give feedback.  Maybe it all looks good, but now the Team Leader has realised that all of these stats are useless unless she knows how many staff are actually manning the phones?

In a waterfall approach, we would point to the requirements document and inform the user that this new statistic for the dashboard is “out of scope” and instruct them to lodge a Change Request with the PMO. Under Agile, we would embrace such feedback – help the user to write a user story and add it to the backlog. Depending on the value associated with this request, we may even build it in the next iteration.

And the rest

These are just a few key concepts, I am looking forward to what others feel are absolutely key concepts for Agile? What at a bare minimum do we need people to understand when first bringing them onto an Agile project?