After we build a better understanding, let's take a look how great facilitation will ease the entire estimation work.
Now let's zoom into some tips for facilitation.
We love visualization!
Support your developers with one of the options below can be helpful.
(1) Visualise past sprint data.
Give your developers opportunities to compare with something they just worked with. Memory is still fresh for all developers.
Imagine if one developer comments,
“This new user story is very similar to the 2nd user story we worked with last sprint.”
(2) Visualise past data in terms of user stories recently completed and their respective sizes.
Now imagine again…
During your product backlog refinement, while looking at a new user story, one developer comments now,
“Oh, this new user story is very similar to the XYZ user story which is at 5 points.”
(3) Multiple teams – many user stories
You might be working with multiple teams while you are developing a single product. If you are curious about scaling, you can check out our scaling skills program.
Would like to share how we worked with dynamic estimation back in 2011.
Back then, I was working with coaching multiple teams working on a large legacy telecom product. The teams were working with T38 Fax Over IP feature. If you are interested in knowing more about the technical aspect of things, here is an overview.
Development work used to be done via competence areas and subsystems. To introduce a new feature, we would have to work on many of the subsystems and components. So… a lot of competence challenges as now we started to work with feature based, instead of component or subsystem based approach like waterfall days.
As we had multiple teams, we were also refining quite some user stories. We experimented dynamic estimation for the very first time, and it was a huge success.
A helicopter recap of the steps were:
Developers started to read user stories which were printed on A4 paper.
The 1st developer who was ready put their user story on the conference table, based on their sizing of the user story.
The 2nd developer put their user story on the conference table as well, positioning it based on their sizing decision (to the left or right, if it was bigger or smaller).
At any time, developers would take turns. A developer could either position a user story, or move an already positioned user story, by sharing briefly their key messages in one or two sentences.
Once over 80 user stories were positioned, developers started to cluster user stories at similar size together, and gave it a story point. The entire process lasted about 90 minutes, and developers from multiple teams sized over 80 user stories (86 in total if my memory serves me right).
Hope the above tips help reduce your headaches about estimation, and hopefully one day you can eliminate that headache entirely. Remember, estimation after all is a Non-Value Added activity.
Summary
Similar logics apply as well for roadmap planning, release planning, stakeholder management etc.Coaching a product is a collaborative and ongoing process. We need to adapt your coaching approach based on the unique needs and challenges.
Empty space, drag to resize
Finally, don’t forget to join our global community of agile practitioners – we have practitioners from 80 countries in our community, across different industrials and a lot of diversities.
