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?
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.