I was recently interviewing with a solution architect. His self-proclaimed role was to consume requirements from business partners, measure those requirements with current software implementations, suggest high-level solutions to agile teams and also give product owners a high-level cost estimate for new projects. He was not a member of a specific agile team, but considered himself a technical mentor for those implementing the architecture correctly.
Already, alarms are going off in my head, because I could not believe that this is an actual agile implementation.
His question to me concerned teams not being consistent with their estimating. He said that a “current problem” that he is seeing is that teams were over-
estimating their efforts, that is, when the
team consumed the requirements, considered the architecture, and provided an estimate, he was seeing that this estimate was much higher than expected when the milestones were broken down into stories. He asked me how I would coach the team as a scrum master to provide estimates that were “more consistent”.
Wow, where do I start with this disaster? As I am writing this, I realize I probably should have just politely excused myself from the interview since I knew that this was not a good fit. Instead I decided to have some fun with it! I turned my answer into a coaching session for the architect. I’m pretty sure I got him to realize that his interpretation of the estimate and the teams’ understanding was different, and to explore that option further. I don’t think that he consciously realized that he was equating story points to hours, and was shocked the hour estimates increased as more was known. However, some simple lessons can be learned from this experience.
Here are some pointers regarding estimates provided by agile teams, whether you are on a development team, support a development team, or are observing a development team.
- Estimating is a tool used exclusively for self-organizing development teams. This means that if you are not on a development team, the estimate is meaningless to you. This fact also holds for any other tool supporting an estimate, like burn-up and burn-down charts.
- Estimates indicate a level of effort compared to work that has already been completed. For example, a medium estimate from a previous iteration and a medium estimate for a future iteration should require about the same effort. It is not an indication of hours, days, or any other duration.
- All teams estimate differently. A medium effort on one team means something different on another team. This fact is part of what confirms that self-organization is working.
- The most efficient teams will deliver the consistent number of points across iterations. The old adage “more is better” does not apply here. If teams are measured against each other by how many points they deliver, then they are likely to artificially increase their estimates to look better. The efficient team delivers the same number of points over a few iterations, and will challenge themselves to deliver more over time. Again, this increase will depend on how well they can self-organize.
- The most mature agile teams will NOT provide estimates for their work. In a complex environment using scrum, the only measure of success is the sprint goals.
This is the agreement or agreements, usually in the form of a sentence, between the product owner and the development team of what will be delivered for the sprint.
Also, it’s dangerous to fund projects and measure results. It’s more desirable to fund products or efforts and measure outcomes. After all, we are not making assumptions on what to deliver, we are partnering with people to make them awesome!
