Our new project is off and running, but we have hit a few snags.  Before we get too alarmed, it is important to remember that it is Sprint 1, and if ever you're going to hit problems this is the time to do it, so they are sorted out by the end of the project.  Incidentally, this is what I see as one of Agile's best features - because each sprint is considered a mini-project in its own right, we get the chance to stand back and assess the situation before moving to the next phase of the project, rather than just ploughing on and hoping for the best.

Towards the end of this sprint, the burn-down seems to have flatlined - for every hour of work that seems to get done, someone experiences a problem elsewhere which causes production to seize up. 

My own analysis of the situation is just that there were too many unknowns at the beginning, and the tasks identified at the beginning of the sprint quickly became out-dated.  This can happen on any sprint, but normally it would only affect one area - this time it seemed to affect the majority of task lists and that's why it's had such a dramatic effect. 

What are the unknowns? 

For me, it's three things:

1. Developers being assigned to domains and/or codebases they are not familiar with.  Although there is some documentation available, it is easy to forget how complex the current system has become, even at a conceptual level.  Sometimes with the resources available then putting developers in unfamiliar areas can't be avoided - besides, learning is always a part of this job.
2. Unfamiliarity with new third party controls or tools.  Until you have looked at the control documentation in-depth and played around with it in your sandbox, you can only take a real guess as to how you would accomplish something with it, and therefore hazard an estimate.   Some controls might implement the entire feature just by calling a method, in others something you would EXPECT to be there, just isn't.  We tend to ask A LOT of our third-party controls, rarely do we find it acceptable to use just out-the-box, so this sometimes requires communication with the vendor support teams.
3. Software Development in general.  I don't think there's anything we can do about this.  It happens.  People will make the odd mistake - underestimating, overestimating, perhaps identifying the wrong approach to a problem.  The only thing you can do is learn from it and move on.

What are we going to do about it?

Well, if you want a highly accurate result then before we estimate ANYTHING, we should have a good, firm understanding of EXACTLY what you'll be doing over the next 3 weeks.  For this, you'd need to design the components and complete any prototyping - effectively implementing the feature - before this would be achieved.  This also is trapped in BDUF world, as opposed to the flexible, feature-driven delivery of the agile paradigm.

Personally, I don't think this is the way to go.  In fact, there are a couple (or more) arguments out there that question the usefulness of task level estimation full stop.  I'm not sure if I'd go that far, although it is an interesting argument.

My own proposal is one that I half-introduced in my last task breakdown, but didn't have the conviction to stick to it, although it made an appearance again in the retrospective.  The basic idea is that you identify as many tasks as you can that you're confident of, and estimate these as normal.  For those areas that you're unsure of - be it the domain, an area that you know will require significant design/architecture, or even familiarisation with a third-party control or codebase - then there should be two 'types' of task identified: Investigation & Implementation.

Investigation tasks are brief descriptions of work that you're just unsure of, for example "Investigate how to bind Control X to data", or "Investigate how to use this new tool" or "Investigate the refactoring approach I need to take".  An estimate is provided for these. 

The Implementation task is a traditional rough guess, probably based on the story points assigned, of how long you think it would take to implement the feature.  A rough guess.  This differs from normal breakdown estimates as you aren't identifying the tasks yet, and people should expect this estimate to be high-risk.

During the sprint, when the investigation tasks have been completed, the developer should then be at a stage where they have a much better idea what is going on.  'Proper' Tasks can then be identified, which take the place of the Implementation placeholder.  In addition, further Investigation tasks may be identified at this stage, and the cycle continues.

A Brief Example

In the above example, we start with an Investigation task at 7 hours and an Implementation task estimated at 14.  Once the first Investigation has been completed, Tasks 1, 2 and 3 will be identified and estimated with some degree of certainty, where Task 3 is another Investigation task from which Task 4 and 5 will be identified at a later stage.  As you can see, the first Implementation estimate had delivery of the feature within 14 hours - but the reality is it took at least 4 + 7 + 3 + 4 + 2 = 20.  A third more than the initial estimate. 

This gives the SCRUM-master (and other stakeholders) a much clearer visibility into the state of the sprint.  They can tell at-a-glance where the 'red-flag' areas are, and have confidence that when the implementation phase begins there are no more 'brick-walls' where a developer can lose days without realising it.

Honesty really is the best policy, even if sometimes the truth hurts.

But with this approach, how is time-boxing possible?

Calculating the exact number of tasks to fit into any given sprint isn't going to happen.  The estimates will either be under or over - the key here is to be agile.  With this approach, I would propose that no more than 50% of the tasks on the sprint should be Must-Haves - this allows us breathing space by letting tasks of a lesser priority slide to the next sprint, if necessary.  50% may seem like a large margin, but the rule of thumb for planning is always to double your initial estimates (and the very worst case scenario is that if a developer finishes early then the sprint can be ended or more work added from the backlog)

This approach also has the advantage that sprint turn-arounds are much quicker - you really shouldn't spend more than an hour or so planning for a 2 or 3-week sprint. 

Based on experience, I'm fairly confident the above approach could resolve a lot of the estimation and task identification issues that we have from time-to-time.  The important thing is that we have realised this early, and taking action to resolve it.

There's a buzz about starting a new project.  A clean slate, the chance to do implement all the new ideas you have - and most importantly for me - the chance to do it THE RIGHT WAY - to put into practice all the things you've learned from your last work.

Software construction is sometimes compared to construction of other 'real-world' projects - whether it be building a house or even installing a new kitchen or bathroom.  There is a tendency for people to think "well, a plumber can look at a job and know that it'll take him 2 days - why can't software engineers do the same?". 

The problem here is that no two projects are ever the same, and even then the tools that we use change all the time.  Imagine the same plumber asked to estimate a job, but this time the laws of physics have changed and water now flows up instead of down, and he's got to use his tools in his left hand instead of his right this time.

Getting the Requirements

So the way I see it, and the way Agile sees it, is to first of all deliver the requirements in the form of FEATURES, which are mini-stories of what the user is trying to achieve.  It's then a case of getting a gut-feel for these features and putting down a relative sizing for each.  If the story is too big, it's further broken down and so on.  But we're still no closer to giving an estimate in terms of hours yet.

My own opinion is this is fine, but the project managers have to be very forgiving of any figures we supply here.  Mainly it's because the stories are still far too lacking in any detail whatsoever (that is half the point!) - but that really doesn't help when you're being asked for an estimate.

The approach I have taken with this project is UI-First.  If it's good enough for 37signals then it's going to work for me. 

But how to liaise with the customer, especially one who, and no disrespect is intended here, can't visualise a software system outside of Excel, Word and a couple of company-specific applications? 

I tried Paper Prototyping.  But I could tell that the customer was struggling with this, and it was definitely running the risk of missed/erroneous requirements.  You know, this old chestnut:

Prototyping

So I switched instead to actually building a workable, clickable, hands-on prototype of the application.  The customer was instantly able to see what their end product would look like, and came back with several new or modified requirements that they were previously unable to visualise.  It also had the added bonus of allowing me to familiarise myself with the UI controls that I would be using, which saves time when I come to fully implement this software.

Okay, so Joel doesn't like it.  Or at least he didn't (that article was a while ago now).  But I would argue the case that I'd never have someone work on a whole week prototyping ONE feature.  

But the way I see it, you don't have to prototype EVERYTHING.  It's not a replacement for sitting down and conversing with your end-users.  Put placeholder screenshots in place of complex dialogs, hard-code sample data values.  It has to be robust enough not to fall over often, but user input should be limited anyway, so there aren't that many cases this should happen.  Having said that, my particular prototype for this app is probably quite brittle, but that's only because it is being demonstrated in a very controlled manner.

Now, from start to finish, that took me 8 hours.  ONE day.  Admittedly, it's only a handful of screens, but that included the time to design the UI and basic data model.  I'm 100% positive that I've saved time in the long run - all it takes is for ONE feature to be misunderstood and you've got a disgruntled user.  It doesn't matter that they haven't given you all the right information - IT'S THE DESIGNER THAT HASN'T ASKED THE RIGHT QUESTIONS.

And In addition, I can now more accurately guage my estimates.  I'll be posting a breakdown of these features soon, using the Agile/Function Points technique that I've outlined in an earlier post.

So it's Estimation time again.  We've been using the Agile methodology for our project management for well over a year now, and while I think it's dramatically better than the waterfall model we had before, I can't help but think we've still to get it right in terms of estimation.

Our estimation technique involves the traditional agile approach of using Story Points, and comparing each Backlog Feature to eachother, and deciding on a relative size.  So, if I think that one story is worthy of size 10, but then I get a gut-feeling that another story will take twice as long to complete, then that story would be sized at 20.

Once you agree on how many Story Points you can achieve in a given cycle (Sprint, to use the terminology), you can select your immediate workload.

Fair enough, estimation is never going to be an exact science.  But I've got that feeling we can be a bit more accurate, or at the very least give reasons for our figures rather than just a shrug of the shoulders and a "sounds good to me" stare.

Function Point Analysis

I've given Function Point Analysis a whirl before.  And it's probably best filed under "Learning Experiences".  Not the best effort, but then I was fresh out of uni and the spec was incomplete, so that's understandable.  Also, I think we were trying to fly before we could crawl.... which is where maybe merging this approach with that of Agile's flexibility might, I repeat, might work.

Another slight criticism of Agile I have is that it's really really really hard to try and estimate how big a task is when all you've got to go on is a sentence from a product backlog.  No spec, no prototype, no nothing.  Okay, so you've got a bit of domain understanding and there's always people you can speak to beforehand to give you a picture as to what's involved, but until you've actually built a picture in your head in terms of Objects, I/O, UI etc.... it's all a bit 'up in the air'.  Admittedly, as is my current understanding, this is okay, and your estimations will get better as the project begins to take shape... but if we performed FPA on each feature then you would need to know, in advance, the following:

• Internal Logical Files
• External Files
• External Inputs
• External Outputs
• Queries

As well as the Value Adjustment Factor based on general system characteristics of the project, this would give some quantitative measurement of what is to be delivered.  And it has proof!  You can go back to someone's estimates and actually find out why Feature A came out as twice as complex as Feature B. 

Agile Function Points

So, this output then is just treated as Story Points are by Agile, in that x number of story points can be delivered in a week, and velocity can be used to guage future performance.

What the engineers are saying is, "look, we don't need a full functional spec and UI screenshots describing exactly how everything will work, but all we need to know is 1) What's coming in, 2) What's going out and 3) How much user interaction is there going to be?".  And the goal donors can say "Okay, so we've not told you exactly how we want it done, but we've given you enough information to go on that you can't come back to us in a month and say that the database schema has doubled in size".

And that seems like a decent compromise to me.