Showing posts with label scrum. Show all posts
Showing posts with label scrum. Show all posts

Friday, 30 January 2009

Burn-up Charts and MuSCoW

Every one knows about burn-down charts in Agile software development: They are a great metric for tracking progess on a project. Less well known, or perhaps I should say less well understood, is another type of highly useful metric: the burn-up chart.

Burn up charts are great for overall project planning and quickly assessing the impact of additional or changing requirements.

Once the release backlog has been estimated into story points, and you have a velocity (or estimated velocity) of how many story points you can get through per iteration, the next step is to make sure the backlog is ordered on the MuSCoW principle: ie. Must-have, Should-have, Could-have, Will-Not have (Yes it is a bit convoluted).
  • Must Have– if these features aren’t in, the product cannot be released
  • Should Have– important but success does not rely on it
  • Could Have – nice to have in, but can be left out if necessary
  • Will-Not Have – not this time
You then can map these out with the y-axis representing the story points int eh backlog (i.e. scope) and the x-axis is the number of iterations (i.e. time/schedule).

Its then pretty easy to plan how many iterations should be needed to complete all the “Must-haves”, the “Should haves” and “could haves”. The sponsor can then decide how much of the non-vital functionality they are prepared to pay for (in terms of time). Similarly, if you add story points by adding or changing requirements, the graph line shifts up, and the point where it meets the x-axis moves out: The number of iterations required to complete the new functionality increases.

Example below:

Wednesday, 10 December 2008

Agile Zealots and the problem with agile terminology

Any change needs people to drive it forward, particularly if it involes breaking or changing existing working practises, or introducing new ideas. Agile software development is no different.

One very effective way of spreading Agile techniques through an organisation is to have small groups of interested, informed people (communities of interest) who can work on developing agile processes and techniques, spread the word about agile and provide coaching and mentoring to adoptors. Having dedicated people who are interested in the subject, and who collaborate on developing it tends to give agile adoption within a company a impetous all of its own that top-down management directives can't always achieve: sort of like the way a viral marketing campaign can be more effective spreading the word about a product than a multi-million pound advert slot shown during the break in "Coronation Street".

On the other hand, communities of interest can also tend to attract agile zealots. These are the sort of folk who see agile software development as some form of religion or political movement attempting to overturn 200 years of corporate economic enslavement going back to the industrial revolution. You probably know the sort of folk I mean: They also tend to be incredibly intolerant of anyone who is not "agile" and even more intolerant of heretics who don't follow their particular true, pure form of the agile path.

These people are a disaster. Before you know it, your communities of interest will be more splintered than the People's Front of Judea as the one that favours Scrum will either be refusing to communicate with the folk who use Agile UP, or worse: actively trying to undermine their work. Soon the rest of the organisation is getting confused, mixed messages and those reactionary folk who are against the whole thing anyway will be sitting back smugly with crossed arms saying "I told you so: This whole agile thing is just a recipe for chaos."

I just found out that one of the agile communities of interest in the organisation that I work in has decided to call itself the "Agile Liberation Front". Never mind the fact that since 9/11 terrorism just isn't sexy and cool any more, this is a prime example of this sort of thinking. Calling yourself something like this promotes the idea that you are some sort of subversive, radical element which no doubt is great for the self-esteem of those involved and makes them seem a lot cooler than folk who write computer programs for banks normally are, but its the sort of thing that makes senior management run a mile. Ultimately, the support of senior management is vital to the success of agile adoption in a company.

On the wider point of terminology, the agile community does not do itself any favours by its choice of jargon. Terms like "Scrum Master", "Sprint", "Pigs & Chickens" etc. appeal to early adopters (the "dude that’s cool" sort of folk) as it gives an aura of something new and different. However, when large financial organisations and mainstream corporations start adopting things, these terms actually tend to become a barrier to further acceptance, as they seem a bit silly or frivolous for management with years of experience in large Fortune 500 enterprises. The point being that there are already perfectly good, well understood terms for these things already: (e.g. Project Manager, Iteration and Stakeholders). Scott Ambler entertainingly rants about this in this presentation.