Velocity and Stories: Agile Development

“We missed that in the spec – never mind, we’ll create a new story to cover it!”

Recently,  I got the chance to work on a project which is using some of the principles from Agile Methodologies that are out there. The last time I mentioned we were using it,  I was watching Agile from an outsiders perspective. Now that I’m experiencing Agile for myself, I have to say its been quite interesting and indeed enjoyable.

So, heres the lowdown on how we’ve been doing it….

Agile: Our Story

 The first eight weeks consisted of 1 project leader and 3 developers (though this varied based on staff holidays and other immediate requirements). The idea was to create a new module which will be used to manage business processes, and to trial Agile Processes to assist in the development. The project is still ongoing, but has already started to bring tangible results, and indeed benefits to the team.

I won’t go into the technical details, save to say it involves c#, ASP. Net and C++ with SQL and Oracle Database back-end on an existing mature system.

Iteratively Speaking

There were several stages we went through,used a lot of new terms, and we were introduced a way of thinking which goes against traditional development processes.  Essentially the process used an iterative approach  which evolves over time. So much so, even the process itself has evolved to suit the needs of the team. I know this is not a new approach, but it is groundbreaking for the company I work for!

Work is carried out in iterations which usually last about 2 working weeks. what kind of processes typically happened during this follows.

Development Review: “Whats next?”

This process, usually  right at the start of an iteration allows the team to discuss, and come up with improvements and suggestions to the original “idea”and/or specification. This also allows the team to concentrate on a specific area of functionality, which can be driven by the needs of stake holders and the project  leader.

In this phase, which can take usually a day or 2, User Stories are generated. This is based on discussions over what is required as priority of this iteration. In our case included a already defined framework-specification which was to evolve over a period of time.  This doesn’t need to be the case, however e.g. “back of a cigarette packet” approach to the spec.

“A long time ago, in a galaxy far far away…”
User Stories are generally written on cards for ease of handling, they consist of 3 card types to make them up:

Storys
What a user of the system needs to do to achieve a goal. This equates to 1 functional unit, and usually comes in the form:

As an <Actor in the system>

I Want to <Do Something>

So that <the Actor can achieve some goal>

This is useful for stake holders to see what is required by a specific functional unit, and also guides the developer in the right direction to achieve the functional goal. This card also holds the total estimated units and the story number on it.

Tasks 

These are the estimated steps a developer needs to do. Generally the idea is to keep the units of work in the range of 0.5 – 3 units. The guideline is that if its too much more than this, then it s too big a task and needs to be split out. If its too small it should be incorporated into another task. These are designated with Story number.Task Number (e.g. 33.1) .

Acceptance Tests

An acceptance test is the test done by a project leader to verify that the work carried out in the tasks is complete.
This gave the steps needed to carry out the test and the expected outcome. there can be several acceptance tests, which when accepted by the project leader sign off the work. These are designated with letters i.e. Story Number.Test Letter (e.g. 33.B)

 Estimates: More than just a finger in the air…..

This development review allows a rough estimate to be placed.  Estimates are not done in actual time units rather an imaginary unit. (as chosen by the team – e.g. “bananas”).  The estimates are based on a collaborative  discussion between the members of the team. The idea is that a developer day is not always a full working day,  as developers can be distracted, disturbed, or can be pulled into other work. This is where the idea of Velocity comes in, to allow a gauge of speed of the development.

Velocity: Its Not Terminal…..

defined as how many imaginary units (e.g. “bananas” ) that a developer would do in an average day.

The Idea is that at the start you estimate the velocity as being low (e.g. 0.5 or 50%) to allow the team to get used to the project.  Then enough stories are put into to match the total units for the Iteration that have been estimated into the future work pile.  this is calculated as:

 Velocity * days in iteration * developers

As each iteration is completed, the velocity is increased a bit for the next, to get the velocity closer to 1. generally this doesn’t hit 1, but ideally (and as has happened on our project) the value gets to 0.7 when at full stretch.

Ouch! That hurts…

But what about things that cant be dealt with as a user story i hear you ask ? Typically the kind of things I’ve seen that fall into this category include:

• Clarification on how something is supposed to function, as it is not currently clear from discussions or from speccing it.
• Investigation of the use of a potential technology to aid in productivity and the user experience.
• Omissions (where a spec is involved) that need to be fleshed out.

this is where a Spike comes in.

 This is an item which cannot be answered straight away and needs further guidance. This allows someone to go and get an answer, or to investigate. This is also estimated, to allow it to be put into the development cycle.

The next phase is to actually to get on with it.

Do the work!

The developers take the discussed tasks and stories and develop. The self organising nature of  the team allows each member to decide which unit of work to do next. This means they can develop to their strengths, and can concentrate on areas of interest and or priority.

At the start of the iteration, User Stories are placed in one of the following phases:

1. Future  Work: This is work that will not be in the current iteration unless the current list of tasks have been completed.
2. Current Iteration: this is the work that is currently in the iteration to be done
3. Awaiting Sign-off: this is work completed, but not yet signed off.
4. Completed Work: Work that has been acceptance tested and signed off.

The rule is (generally) that a developer should only be working on one task in the current iteration. To keep track of progress a daily briefing meeting known as a Stand-up takes place to keep track of progress during the iteration

Standing room only

The team gets together daily to discuss essential development points since the previous meeting / stand-up. The idea is that standing up keeps the meeting to a minimum, because it’s generally uncomfortable to stand around too long. This keeps focus on important points.  Everyone is then aware of the progression of the team towards the end goal.

The typical things discussed are:

• What has been done since last meeting (each member)
• What is going to be done for next
• What problems and challenges encountered
• Status from external stakeholders on specific functional issues

This in our case meant that stand ups only last around a few minutes, unless there is a significant technical issue. These were usually handled as a separate technical discussion, between developers and not with the project leader unless it affected functionality.

Why Agile Works for us?

• Allows flexibility to be put into the design.
• The functions evolve as iterations pass and work is reviewed.
• A collaborative approach engages all relevant members of the team and the stakeholders.
• The work is in easily digestible units.
• Developers Feel ownership over their work.
• Better estimations of tme taken to complete the work.
• Early sign off of work, close to the development time.

So what do I think?

I’m sure there’s more that can be done to make this truly agile,  For example:

• Shorter release to market times.  In reality this might not have been possible on our product due to the nature of our customers and the maturity of the product. Also the module is some way off being available for RTM.
• Agile from the requirements phase. this means the design would then be driven directly by stakeholders

I’m sure I’ve only scratched the surface of the tools and methodologies available, but hopefully this gives an idea of how we used it and the benefits of using Agile Software Development.

The use agile methods can be controversial and sparks a great deal of debate. Needless to say I’ve become a proponent of this so far. I recommend that you research more into Agile and what this means, so that you can use the available tools to suit your needs.

Further Reading

This wikipedia page gives a good starting point for reading up on it. Any more links that you can find would also be helpful!