Who is to blame? | Gatesworld

2011-08-11T04:57:00.000-07:00

The importance of estimating in Scrum

2010-05-10T15:04:00.001-07:00

I often hear business managers reject agile processes because they cannot accept vague estimates. These same managers are usually surprised to learn that agile estimation is far more accurate and disciplined than traditional methods.

Some of the misconceptions stem from rogue developers (or teams) who refuse to be pinned down to an estimate – often out of fear of the repercussions of getting it wrong. As a business manager – or product owner you have an absolute right to accurate estimates. You need to plan accurately, evaluate your business case and ultimately commit to spending the money. Scrum provides a solid mechanism for providing these accurate estimates.

This article makes no attempt to explain how estimation works because that is covered in lots of places. Instead it will try to provide some tips for accuracy and highlight some common pitfalls.

You can’t estimate what you don’t know.

Gut feel doesn’t work. I have often been asked to estimate a project on the basis of a one paragraph description on the basis of my experience. Sorry but I can’t do that. It doesn’t matter whether you are in an agile environment or not. Equally it is not possible to accurately estimate based on part of the requirement with the rest of the details to follow once the project is underway. If its important enough to require an accurate estimate, a business case and funding its also important enough to spend time, effort and money to establish the product backlog and get the estimates right.

Very often a major project justifies a separate initiation project to establish these. And why not! In the days when I was a consultant for a large waterfall based organisation it was fairly common to provide a quote for the specification and estimation process and only deliver the development estimate once this had been completed.Just because Scrum doesn’t require big up front design doesn’t absolve us form the responsibility of understanding what it is that needs to be done. Sometimes this is referred to as sprint zero, with the objective of this (non) sprint being to deliver the product backlog, estimates and release plan. Those who advocate the sprint zero concept generally agree that this should be shorter than a usual sprint. Great for small projects but if that’s not enough then a separate project may be warranted.

Tackle the risks early

Often we hear scrum practitioners talk about commitment based planning. In essence this means asking the team to commit to what they believe they will achieve in the first sprint and using this as the starting velocity. This can work if the team is established and the work is familiar. It is not feasible when the work is unfamiliar or we are proposing to use different technologies or platforms. The only way to establish an accurate velocity projection is by doing some of the work. This can be undertaken as part of the initiation project or sprint zero and should be planned and budgeted.

Recognise the difference between an estimate and a commitment

Failure to do so inevitably leads to padding. New requirements may emerge, external factors may change or we may simply have got it wrong (especially if we tried to short circuit the estimating and planning). Part of the Scrum process is the concept of insect and adapt. This also applies to estimates and projections. My own experience has been that by the end of sprint 3 the velocity can be established and the burn down projection is pretty accurate. It is vital to inspect and adapt after every sprint. If your velocity is way off expectations now is the time to say so. It would be foolish to believe that you can pull it back by working harder. The beauty of tracking velocity is that it is based on actual achievement, and if that is different to what you expected you should highlight and plan around this early.

This is one of the real benefits of using relative sizing and estimation based on functionality rather than activity. In traditional waterfall approaches the first activity would be specification. What does it really mean if this overruns by 50%? Do we adjust the entire project by 50%? This is not really valid because there is no relationship between the size of the specification and the rest of the project. Or do we just assume that everything else is going to work to plan. Equally if the specification is completed exactly on schedule this provides no indication of how the rest of the project will go.

If we use relative sizing we can accurately forecast the rest of the project based on current performance because the relationships remain constant.

What about contingency

This question will usually be asked by financial managers and those accustomed to projects exceeding budgets and / or schedules. Well what about it! Scrum estimates are based on how many story points the team can achieve in a given time. We know how many story points we have to get through. We know what the team can achieve per sprint and we know what the team costs to run. If the scrum disciplines are followed and we continually inspect and adapt the project should come in slightly cheaper than the original estimate. Why is this? Well, we assume the team works full time on the project. I am not suggesting that they don’t but the cost estimate may be something like this:

Cost of team per sprint (a)	£5000
Number of sprints (b)	26
Total Cost (axb)	£130 000

This does not take into account bank holidays, annual leave, sickness or time spent on other activities such as training, admin etc.

Remember the basics

Inspect and adpapt!

Scrum has no formal change control procedures because scrum itself is about managing change. When new requirements are added to the backlog we need to review our estimates and forecasts. Because we use a prioritised backlog to deliver the highest business value first this may be as simple as recognising that the items at the bottom of the list won’t get done. This is managed by the product owner. Sometimes this may not be possible and the time and / or costs may need to be revisited. We cannot regard the original product backlog and estimates as a contract and expect the ability to add requirements at will and have these delivered in addition to the original list at the same cost. (It’s amazing how many business managers fail to – or choose not to – recognise this.)

Define what done means up front!

We want to avoid surprises. If the customer is expecting user documentation as part of the release and we are assuming that this will happen after we have completed our bit the product will not get released on schdule. This is just one example but one that often gets overlooked.

Time for Linux users to get a life

2009-12-29T14:13:00.000-08:00

I was bored this morning and spent some time idly browsing around slashdot. In amongst the usual collection of "Microsoft is Evil" posts I stumbled across this gem:

Those who fear the CLI shouldn't even own a freaking computer. Crybabies and whiners. "Oh, I can't do ANYTHING, unless there is a pretty picture for it!!"
Sit your sorry ass down with the manual for MSDOS 5, 6, or 6.22 and LEARN the basics of computing. Then, pick up another basic - it's called BASIC. From there, you can branch out to some scripting languages.
Run a machine for 6 months with absolutely NO GUI installed - then you might be competent to talk about how good, how bad, or how inconvenient any part of a computer might be. Including the CLI.
You probably can't operate a standard shift automobile, or roll a window down unless it is electrically powered.
Mindless putz.
How do you avoid putting your bra on backwards?

Well I'm a Linux user and administrator. I personally happen to believe that the Linux desktop is ready for prime time. I am also an advocate of open source software and would love to see Linux more widely adopted.

Many distros are ready for this and are intuitive, stable and easy for non technical users to sink their teeth into. The biggest shortcoming is documentation, or lack thereof. This is widely acknowledged in the community and there are initiatives to improve this.

There is still a widespread belief that Linux is for geeks and that these geeks won't help mere mortals. And while that belief persists Windows will continue to be the dominant desktop OS. The average user does not care how stuff works and does not need to; in the same way that a driver does not need to understand how an internal combustion engine works.

Like many others I use both Google and community forums as a resource. Unfortunately many Linux users perpetuate the stereotype. Comments like "Google is your friend", "this is documented elsewhere" or "go and try on your own for a few days before asking on here" are simply not helpful and will not convince new users that this is the way to go. I have happily dropped several open source projects for this very reason (and some of these were very good products).

As an IT pro I am happy to do the research, but if the information is not easily found I am simply not prepared to spend days trying to figure out simple problems. I can go onto a motorcycle forum and find 100 threads on recommended Tyre pressures. Not 100 posts saying that this has already been discussed.

Fortunately there are helpful Linux users out there and not all communities are made up of geek cliques - but for the rest of you:

You really can't criticize others for their choice of OS if you won't help them understand yours. A computer is just a tool for doing a job. Most modern operating systems are equipped to meet the needs of the average user. Its not really surprising they choose the one where other users don't treat them like fools.