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.
Doing Agile from the bottom up as an internal team is very different then having an external coach brought in by the organization. As our Agile Journey starts it needs prioritization. Not the product backlog, the Agile implementation. Changes have to start small. They are gradual and can only impact this team. For maximum effectiveness benefits are as far-reaching and highly visible as possible. Success or failure is in full view of the organization. Knowledge, planning, passion, and teamwork will stack the deck in favor of success. Success breeds buy-in from above.
To do this alone would be nearly impossible. On a team of four developers I am the most junior. While my overall IT industry experience is on par with the rest of the team, they spent all of it in development roles. For me it has been just under half, with the non-development experience at a different company. Our project manager was let go at the beginning of the year. I was not yet in a position to take on the role and it was given to our lead BA. There was a catch. It become a dual role of lead BA and project manager. This was already a stretch role. The knowledge gained while earning my certification gave authority to my offer of help. The pending maternity leave of the other BA made the need for help painfully obvious.
At the end of April I became certified in Agile Practices by the Project Management Institute. There is nothing magic about a certification. What the PMI-ACP does for me is show that I have experience in Agile practices, gained enough book knowledge along the way, took an official Agile Methodologies class, continue to learn more via approved learning methods, and care enough about all of it to spend money showing the accomplishments. While that last one is technically true it is not exactly proven by the certification. In fact, my employer reimbursed me for both the class and test. (In my defense I only learned that this would happen after I committed to making it happen.)
What does matter is what happens next in my professional life. How do I use this in my career?