Is it bigger than a breadbox?

In the waterfall method of project management, we are asked to estimate how long a large piece of functionality will take to complete.  Then, all of those parts are added up to get a timeline of when things will be done, and we’re off.

As humans we can estimate how long a small, simple task will take relatively accurately.  When that task becomes larger, and/or more complex, we rapidly get worse at estimation.

Agile methodologies ask us to break the tasks down into smaller bite-sized pieces, which allows us to more accurately estimate how long a task will take.  If this is true, then why do people still do relative sizing in agile projects where the tasks are broken down appropriately?

Experience

Where both of these systems fail is when you take into account who is doing the work.  We all know that each developer works at a different speed.  There is often a strong correlation between the speed at which a developer can complete a task and their experience level (though, there are certainly times when this is not true).

So, now let’s imagine that we have a team of 5 developers and a rather large project we want to complete.  When we go to estimate, who’s estimate do we take?  Do we go with the lowest estimate, the highest, an average?  Do we divide the work up among the developers and get them to estimate the work they are assigned and hope we divided fairly evenly?  What about vacations, sick time, or someone leaving the company?

Relative sizing to the rescue!

Ok.  So, like anything this is not a panacea.  It works, but it takes effort and commitment to make it work.  Let’s start with a definition of relative sizing.

Relative sizing is simply the process of looking at the stories and determining how big a task is in comparison to other tasks.  The nice thing is most people will agree that task a is smaller than task b most of the time.

When doing relative sizing, most teams pick some series of numbers to assign to the sizes (we used powers of 2, others do prime numbers).  When picking numbers, I suggest not using 1,2,3,4… since this is too fine grained (you want some wiggle room).

Now that you have a scale, each team member can give estimates on tasks using these numbers.  When there is a discrepancy between team members, use that as an opportunity to discuss why there are differences.

Sometimes the difference is because the task is unclear, and this gives you an opportunity to clear up any possible misunderstandings.  Sometimes one developer knows something the others don’t and he/she gives a very different estimate.  This is a good learning opportunity.  Sometimes you will have very small discrepancies, like one developer estimates a 2 and the other a 4, there may not be any differences in understanding, just one thought it was bigger than the other, in that case we typically went with the larger estimate, though you can make your own rules.

You may be wondering how assigning tasks points is going to help you determine when a project will get done. Good! Because I haven’t shared that yet.

After you have points assigned to your cards you will need to plan out a couple of iterations (a defined period of time to do work, often 2 weeks).  Ask the developers how much they think they can do in this iteration and only put in the tasks they think they can accomplish.  After a couple of iterations, you can add up the total points the team completed and take the average.  That will be their velocity.

You will notice when a team first starts out their velocity will probably fluctuate as they get used to estimating and working on the new project.  Be sure to keep an up to date feel for their velocity.  I would recommend not using all of the previous iterations for the average since you may have some anomalies especially at the beginning.

With their velocity and the stories estimated for the project, you should be able to project when a project will be complete.  And, you don’t have to go to all of the trouble of assigning out tasks to individuals!

 

Advertisements

Starting an agile project with a new team

At the first job where we were trying to do agile, none of us knew a lot about what that meant.  We didn’t break down our work into stories, therefor we didn’t estimate any stories.  We simply divided up work that needed to be done among the pairs and did pair programming and test driven development.

Then, the next job where I was doing agile, we didn’t estimate our stories using story points.  We estimated in hours, kind of.  We used a set of hours that we could pick from, it was either 1,2,4,8,16,32 or 64 hours.  This allowed us to stop fooling ourselves that we could be very accurate in estimating a task that was going to take longer than a couple of hours.  In order to determine how much a pair could accomplish in a sprint (which were one week long), we simply found 32 hours worth of work and BINGO.

In my current job, I am trying to bring more agile processes to bear.  I am in charge of a new project at work and have decided to run it in a completely agile manner.  I am the scrum master (which I have only kind of done before, mostly for myself).  The project has only one developer resource.  We have access to a QA resource as well as our user experience designer, though neither of them have any dedicated cards.

The developer on this project is a contractor who is not familiar with the code base, nor with the system that we will be integrating with.  We have not worked with him before.

Our first task was to introduce him to the project and then estimate the cards that we had created.  Rather than going with hours, I decided I wanted to use story points.  Our scale is 1,2,4,8.  Anything that is sized over an 8 needs to be broken down.

After a long estimation session, we needed to determine what work would go into our first 2 week sprint.  In an existing team this is fairly easy…just look at the average velocity and put that many points in the sprint, adjusting for any absences.  But, what do you do when you have a new team and have no idea what the velocity is?

You guess.

That’s right.  Look at the cards that you want to play and start adding things to the sprint until the team says stop.  Then, make sure your backlog is groomed well so if the team guesses wrong and can pull more work in than they thought, they can pull from the top of the backlog.

If the team doesn’t get all of the work done that they committed to in this first sprint, don’t hold it against them.  The first couple of sprints are learning sprints.  The team is learning the code base.  The team is learning the process.  The team is learning what their velocity is.

After a few sprints you can take the average velocity and start using that to plan out the work.  If your team is consistent with their estimation, and is fairly consistent in their velocity, you should be able to fairly accurately estimate when different features will be complete.