digitalart – FreeDigitalPhotos.Net
As I mentioned in my last post I would like to create training. For some reason I feel like Estimation is a decent place to start. I think a one hour online video training session is something I could probably produce. I would also like a longer interactive one of 2-3 hours. I think that is long enough for estimation.
It isn’t long enough for Agile though. The training will come with the assumption that the attendees understand the Agile concept of making decisions and commitments as late as responsible. This will be briefly addressed, but it will not be gone over in-depth. Concepts I hope to cover include reasons for estimation, value versus cost of estimation, when to estimate, estimation techniques, and estimation red flags. The target audience will be teams new to group estimation, new scrum masters, and project managers new to Agile methodologies. Continue reading
I have written about estimation before. I have written about Planning Poker before. Today I am going to do a simple beginners guide to Planning Poker. The difference is that this guide is meant to be used by you. You could use it as a presentation presenting the idea of Planning Poker. Alternately it can be used to teach a team and run the first session. With that frame of reference in mind let’s get started.
How many of you like to estimate as a team? I do. I find it an easy process with lots of value for everyone involved. What if I taught you a method that will get your team rapidly reaching a consensus while estimating? These estimates will be accurate enough for iteration planning. As a side benefit, the team will have a better understanding of the product and its future direction. The process is lightweight enough to keep the team engaged. The end result is estimation meetings that are not dreaded by anyone. Continue reading
Image courtesy of Graeme Weatherston / FreeDigitalPhotos.net.
Estimates are kind of a big deal. I’ve written about them before. (See here.) Last year was a big one for the idea of completely dropping estimation in the greater software development community. In July the twitter account @NoEstimates was taken on as an outlet for Woody Zuill specifically for sparking discussion on this idea. Ask any person in software development what they think of estimation and they’ll share their opinion with you. Mention the idea of not doing any estimation and it could get heated.
The “No Estimates” crowd has some good points. However I believe all out “No Estimation” is gouging out an eye to spite the face. What I feel the right answer is, and the one I have seen from various thought leaders this year, is “Valuable Estimates Only!” It just doesn’t roll of the tongue as well. Continue reading
Earlier I introduced the concept of Planning Poker for estimation. (Part One. Part Two.) This has continued to be a very good tool for our team, and specifically our project manager. While most notably used for estimation, that is only part of the benefit that is received by using a process similar to Planning Poker. To our team the interaction between the team and the product owner coupled with the team wide understanding of upcoming user stories are bigger benefits.
When I first introduced this new form of estimation to the group I made a mistake. I did explain the concept of story points to the group and even had cards made to represent them. The cards all had graphics backing the central number to help frame them as relative effort. Boxes play heavily into the product we develop, so I had single boxes, groups of boxes, and pallets of boxes for the story points. I also created a separate set of cards for estimating tasks and bugs. They were to be done in hours, so they had cards with numbers and no background. The mistake is that the story points were set up with the same set of values as the hours.
These have been the three most underutilized and ignored fields in our TFS template for over two years. We did an entire application re-write with three major release milestones, multiple integration points, and multiple small maintenance releases hardly acknowledging these fields. What little estimation data the project manager received was from one person on the team. Actual information was never fed back in. Estimations were broken. It was increasingly difficult for the project manager to reliably communicate with the business what the team could accomplish at what time. This was the biggest pain point we could identify.
Our bottom up approach to Agile implementation started here. As long as upper management received time based estimates on features for Enterprise planning purposes they were not especially concerned with where they came from. They cared only for how accurate we felt they were and how accurate they ended up being. That mindset allows us to change our estimation methods with little fear of interference. This is likely a common state for a project team to be in.
I covered the three main reasons I use Planning Poker last week. This week is about how planning poker plays out in an estimation meeting.
The best way I can think of to see how planning poker works is to show it. The estimation will be for a trip from Minneapolis to Chicago. The Product Owner has called her group of developers together to provide an estimate for the customer. The developers are all the people who will do the work on the trip. An analyst might be used to better define the trip parameters. A developer may be used to build the trip based on the parameters, but usually there will be more than one. Someone else may be testing a model of the trip to ensure it satisfies all parameters to the best of the teams ability. The people involved may or may not know a lot about the other roles present. For this exercise the important thing is that each person doing work for the requirement is present to estimate it.
How long does it take to travel from Minneapolis to Chicago?
Give a group of ten people this question and ten answers will come back. Some may be radically different. People have a lot of trouble estimating how long something will take, or how big something is. I see this in my own life on almost a daily basis. How long will it take to change the brakes on the car? On the van? Cook dinner? Each time I think it will take a different amount of time, and each time it does – but I am still wrong about how long.
This is a problem when a business is trying to plan enhancements and future projects. The good news is that while we are bad at straight time estimation, we are usually pretty good at relative estimation. The brakes on the van will take a little longer than on the car due to the size difference of the vehicles. Dinner today will be quicker than yesterday’s because of the dishes I am making. A trip to Chicago might take twice as long as a trip to Ames, but it could be half the time as well.