Agile Product Development w/ Scrum
How long will it take and how much will the project cost? Estimating effort to me is not a tool as much as it is an approach to answering the “how long will it take?” question. I am using this approach to figure out how much Teams can commit to for a given Sprint and then predict how long the project will take. In addition to its primary purpose, estimating effort provides 3 major benefit to Teams. This blog explores what I am getting out of Estimating Effort.
Before I jump in, I should cover how I facilitate estimating effort. I use the Fibonacci number set, 1,2,3,5,8,13,21. Everyone votes. This includes the PO, Team, and Customer or Stakeholders if present during Sprint Planning. Each Product Backlog Item or PBI is voted on until the Team feels as though enough work has been selected. To get started I calibrate everyone on what an effort of 5 represents from the Product Backlog. Once we all agree on a PBI which represents an average amount of effort (5), I then have the Team estimate the remaining PBI’s.
Estimating effort for work packages on a development project can be tricky. There are several roadblock to mitigate prior to getting a credible estimate. Break through these barriers and you will really start to understand how much work your Team can take on in a given Sprint, and you will be able to better estimate how long the remaining work will take. This is the 1st step to answering the ever elusive question “how long will it take?” Here are three key benefits of Estimating Effort.
1. Alignment
1st key benefit with Estimating Effort. Alignment: Each PBI is discussed in detail with PO prior to working on them.
The idea with alignment is that the Team discusses with the Product Owner what the product backlog item includes. The Team talks through this detail since they are the ones actually doing the work. The conversation yields a Definition of Done between the Team and Product Owner. The Scrum Master facilitates the discussion and documents the Definition of Done as well as the estimated effort value for each product backlog item.
2. Clarity
2nd key benefit with Estimating Effort. Clarity: Any misalignments are exposed while voting with the PO.
For example, if the PO votes a 3 and the designer votes a 13 then we have a disconnect. So, before we start detailed planning, I want to make sure everyone is on the same page with respect to how much effort each PBI will take. The Product Owner may be thinking a few days of design and ordering parts, when the Designer is thinking 2 weeks of analysis and research, 5 days of design, a design review, and then order parts. By discussing the work, and then voting I am able to address disconnects real-time.
3. Doable
3rd key benefit with Estimating Effort. Doable: Any 21′s indicate the PBI is too large and needs further deconstruction. #scrum #pmot #agile
Generally speaking, it takes 3 Sprints through a Scrum cycle to get the Teams average velocity. Before I have the average velocity, I cannot estimate if the Product Backlog items represent too much work for a single Sprint. So, I have chosen to have the Team reserve the 21 vote for PBI’s that are too large to complete to the Definition of Done in a given Sprint.
Gone are the days where I tell the Team how long they have to invent something. Instead, I facilitate the Team through an estimating effort exercise every 30 days with the Product Owner and Stakeholders until the next steps are clear. Then, once we have an average velocity I can better estimate the long term plan…this beats the “crystal ball” method.