Sustainable pace

January 2, 2009









Good things:


Bad things:




Estimating tasks with points

September 17, 2008

Following on from my entry on the altnetuk session on Agile Process, I’m just going to layout the different types of estimating with points that I know of. I’m not sure why but at that session it felt like someone had put and end to point to complexity estimating and forgot to let me know!

Pure time based estimates

You’ll be wrong. The time it takes for dev a to do a task will be different to the time it takes dev b. You will run in to problems with the task and it’ll totally throw all your estimates out (may be exaggerating).

Your manager will not understand why you can’t do 7.5 hours worth of work in a day. There is no room for ramp up, context switching or any of those minutes you don’t think of.

Burn down charts tend also to look like complete failures. As every hour of your day is accounted for, but you don’t actually spend every hour of our day on storied tasks, those other hours show up on a burn-down chart as slacking. When this happens, it’s not reasonable for the team to commit to less in the next iteration, as it implies they’re not spending their time doing any work. This totally ruins the point of committing to any work in a planning meeting, if there is little or no intention of completing it all. This also makes it difficult to ball park future iterations.

Time to points

The team eventually manages to estimate tasks without thinking about the time it takes. Easy to figure out your capacity or velocity. Easy to manage when team size fluctuates (illness, holiday, expansion). Easier to sell to management. No room for improvement, how do you increase our velocity without making time? It’s possible, but only by admitting that you’re not estimating with time any more.

Pure points

Difficult to start a project with a new team. I do this by assuming we’re unstoppable and committing to all the stories we have. Then I use the number of points we do complete as a baseline for the following iterations. Motivates developers quickly. Increasing velocity in this way is far easier to motivate developers with. The idea that you’re getting better at doing work is much nicer than the idea that your old estimates were slack. More quickly with pure points do new developers fall into line in planning poker. They stop influencing the task with how quick they think they are (maybe quicker than some of the team maybe slower) and go straight to how complicated the task is. Points always help when you get estimating discrepancies. More clearly separates your teams estimating technique / accuracy from another’s. With a per team velocity and meaning for points, it’s more difficult for management to unfairly compare two teams estimates and use it as a flawed performance indicator.

Agile session Alt.Net London

September 17, 2008

So to start the conference I chose to take part in a session about agile development and processes. I think mainly because I wanted a refresher on some of the points and to see if I could contribute. It’s nice to see plenty of people there new to Agile as I was at my first open conference. Learning the basics of the process, and making a good start. I was also interested to see how people had developed from their initial attempts at introducing Agile to their shops.

At one point there was a lot of talk about how we estimate, and I was surprised to see that everyone had assumed estimating in hours and half days. Assigning some time to points and then estimating with points. I wonder what happened to estimating by points representing complexity. At uSwitch, when we introduced planning meetings and planning poker, we started with 5 points to a day. This was mainly to get developers used to the idea of estimating in points and as a team. Over time in teams where this method had remained, they have naturally loosened the tie between the points and the number of hours they represent when estimating. They still use the rule to define how much capacity they have in a given iteration, 5*Devs* 10days = capacity.

For me and my teams, we’ve moved this to the next logical stage of entirely decoupling estimation points from time and tying them to the complexity of a task. Has this gone out of fashion and no one told me?

I think I’ll break this off into a separate post on estimating

Crystal and full project breadth

Ian Cooper shared with the group the method or agile flavour he’s using with his current team, it’s called Crystal and sounds interesting. It sounds like the emphasis of crystal is the continuous improvement and customisation of the process to your team and project’s needs. A quick bout of googling tells me that the following has not much directly to do with Crystal. From what I’ve been able to gleam (and it’s not much) Crystal is primarily focused on improving methodology frequently, aiming to minimise it’s weight.

The main point that Ian brought up that caught my attention was the move from the pure priority prioritisation to a more whole system or breadth approach with incremental refinement. Purely working of stories by priorities, apparently leads to systems that have a lot of work and attention spent on apparent high priority sections while those features and functions that the client may deem as a lesser priority are essentially neglected, typically tacked on the end of the project. This can lead to seemingly unfinished projects (my conclusion).

The three thirds approach that Ian described seems to encompass the entire system with increasing levels of ‘focus’. The first phase is the ‘Walking Skeleton’ this is just enough of the entire system to get something going from a technical perspective, this might take up most of the ‘framework’ stuff that one has to do to get a project going. Many people likened this to an iteration 0, which doesn’t deliver much or any business value but is necessary to build something you can demonstrate.

The next phase delivers the ‘First Business Value’ taking the walking skeleton and adding enough to actually add to what the business has, making a contribution.

Here is where my notes get a little woolly and I wish I wrote this post while I was in the room! The final phase adds all the other features, improves on the initial business value, works on feedback from the client on the second phase, and perhaps includes changes to requirements.

From the weakness of those last two paragraphs, I think I’m definitely going to do a little more research, so check back for a bit more bulk in later posts.

This notion of increasing the focus with subsequent iterations really did intrigue me, and I’m definitely going to see how I can apply it to our next project.