Story points.. if you must

To be up front,

I haven't introduced or taught a team about story points for around 4 years,
I like to help teams use slicing techniques and data to inform their forecasts.
This approach has been informed by my own experience working with teams and some reading (some of which is linked below).

This note is not about not using points, moreover, acknowledging that some teams do and a reflection on what are some of the practical things that may be useful... if you must. (Alternative approaches post in draft k posting soon).

As a coach I believe its important to approach teams where they are, observe & discover what works for them. If that's story points- what practices and principles may help?

Relative?

Story point estimation is a whole team practice driven by a shared understanding of the items being estimated as well as the method and relativity of the points themselves.

Its useful as a team to agree on

a single point backlog item- something where there is general consensus that can be used as a benchmark. Consider this as part of a team working agreement conversation and revisit this periodically to discuss if its still valid as this will change.
The number sequence- does the team have a shared understanding and agree on the sequence (points relative to each other), having an aligned view on the use? ⠀⠀⠀⠀

All in?

As mentioned above, breaking down the work should be a whole team activity, it's great to get different perspectives from everyone in the team. Who is involved in estimating the work? everyone in the team.

Don't just do it

alt text

This may sound obvious but what are you doing it for? Some teams can get stuck in "planning inertia", focussing a fair amount of time and effort in estimating, only to not use this information to inform prioritisation decisions or plan sprints without reflecting on prior sprints. What did we get done? What did we learn by doing the work? What shall we plan for now? Use the estimates you all spent time on. Its great to inspect and adapt this practice too.

Refining

Its great to reflect as a team about the practice of refinement- specifically what a great outcome might be for the team. Breaking down the work together, developing a shared understanding on what & why, adding detail and reviewing together. If the outcome is just "getting to an estimate", you may end up skipping some useful elements of this practice.

Feedback loop

Consider conversations with teams on what we learn through these estimates. With a scrum team at a retro, what did we learn from the work we completed during the sprint. Items that were more complex or less complex than we thought are a good topic to reflect on. How might we share and apply these learnings to similar work?

Try not to forget.

Perhaps goes without saying but sometimes forgotten....

Story points are:

Not a target, the outcome you are trying to achieve is.
Not a measure of "team performance" - its an estimation practice.
Not a way to measure how one team does compared to another
Simply one way to forecast, nothing more.

Its not the only way, don't forget "We are uncovering better ways of developing software by doing it and helping others do it."

Ron Jeffries - https://ronjeffries.com/articles/019-01ff/story-points/Index.html

Neil Killick- https://neilkillick.medium.com/my-slicing-heuristic-concept-explained-810ee70b311e

Melinda Harrington: https://melindaharrington.com/2018/05/18/dangerous-metrics-from-an-ineffective-scrum-master/

Further thought if you read this far, if you don't know Shia Labeouf and his motivational green screen video (source of the image above) try: https://www.youtube.com/watch?v=ZXsQAXx_ao0