"Let's
use Story Points
Why?
We
are following agile now
Yayy..
story points!
How
many hours these epics, stories will take?
But
we are using story points..
Yeah,
but we still need to plan. Hours are better for that. 1 SP - 5 hours. ok?"
Heard
this story of story points many times.
-----
It
is important to understand why do we need Story Points? Is it mandatory for
being agile? Are hours prohibited?
The
key motive for story points or hours is that we need to estimate the work, so
we can tell what can be achieved in given time. Hence, we try to estimate.
Hours are used since long because time is easy measure for us, and we can
quantify easily, 'accurately'.
However,
it become challenging when we found that even after best try, it is hard to
estimate the time. It is more and more true in non-mechanical activities, where
outcome depends on many intangible factors like skills, information available,
mood, motivation, environment and so on.
If
estimates can not be done accurately, then why to estimate. Let us just keep
working and ship whatever is done. And this is also one of the philosophy and
may work in specific setup. However, most still need a roadmap with understanding
of possibilities which feed into overall plan of business.
'Possibility'
is the key word here. We gradually understood that accurate estimate is not
semantically and practically right. However, we can try to have best guess
based on available information, which reflects the possibilities. As long as,
we accept this fact, that we are talking about possibilities, hours or story
points or tshirt size or anything else works.
If
we consider this, ultimately, it boils down to 'common understanding'. Common
understanding that when we are estimating, we are talking about possibility. If
we all are good with this, any unit can be used for estimation.
Building
up on this understanding, let us talk about common understanding. How easy or
difficult is it to have common understanding with many people of different
skills set, experiences, background, motives, different stakes and
responsibilities. There are so many psychological factors, which makes it
difficult to have this common understanding, more so if unit of measurement
(hours) is traditionally used for accurate outcome. As soon as, we say x hours,
it triggers a mental understanding of accurate number and then we want to see
that getting materialized. People usually understand that estimates are just
estimates. But as soon as we attach it with Hours kind of definitive measure,
it build up expectations of accuracy. This is the key challenge to address.
To
address above challenge, efforts were made to bring some kind of abstraction.
That's where Story points help. With story point estimation,
- We are not
estimating individual story, rather we are estimating 'stories' relatively
in respect of each other. It removes the feeling of accuracy, being
relative.
- We are
separating amount of work and efforts required to complete this work.
Story points reflects amount of work (considering complexities/risk etc)
Which helps in having common understanding faster. It is easy to agree on
amount of work, than for efforts required to complete it.
- Estimates
are given by team, for team. These does not reflects any individual
capacity. Hence we are focused more on team capability, rather than
individual stars.
Let
us take an example
Team
A is based in Singapore, have 5 team members. Team does outdoor activities
every month, which is relay cycling. First month, they choose from office to
East Coast park. Because whole team is familiar with area, it was easy to
settle on distance estimation from office to park (assuming no google map :) ),
say x km. Everyone agrees after some discussions, that it feels like x km, normal
route with good roads from office.
How
much distance each can cover depends on individual cycling speed, practice,
fitness, cyclic condition etc. Hence, distance covered by each team member can
vary a lot. Team agrees that everyone will cycle for a given time. Distance can
vary based on individual capacity.
First
month, member A cycles 'a' km, B covers 'b' and so on. Finally team covers y km
in decided time, which is equal to x-n, few km less than actual park distance.
Next
month, they went again for same route. As they already have experience of this
route, they knew in advance that how much they can cover. However, when they
cycled, weather was nice and hence members were able to cover few more km due
to pleasant environment, ie y+n.
Next
month, same route, they were able to cover whole x km. Because team got
experienced about route, knows all the turns and hurdles, and members were also
getting more skilled in cycling.
Following
month, they picked a new target. They agree on distanced which was Y km. This
time, as they are well aware about team capacity, so they set y-x as first
month target. And they were able to meet that.
Next
month, they went again with same target. But they were able to cover lesser
this time, because one team member was not in good mood and hence was cycling
slow.
After
cycling for 5-6 months, now they know how much they can cycle together in
relay. They know each team members usual capacity, and capability to manage
hurdles. They also consider other moving factors while calculating like mood,
weather, road conditions etc. And accepted that these can again change anytime
to either side.
In
this story, distance/complexities from office to East Coast park is Story
Points. Which is an estimate of total work, not the time needed to cover that.
Total time to cycle is the sprint duration, which is fixed based on
whatever team thinks appropriate. The average distance covered by team over the
months is the velocity of the team.
Overall
team knows their capacity now (velocity) and can try to estimate any new target
based on this understanding in much better way. But they are still open for
variation as there are always many moving factors.
Team
B is based in USA. They are also doing similar relay cycling. They interact
with Team A once in a while to discuss. To their surprise, they were covering
much lesser distance than Singapore team. On further discussion, they found it
is because they have many new members in team who just started cycling and
weather is also very cold which slows down the pace.
Finally
both understand and agree, that velocity of Team A and B will be different as
team, experience, weather, geography is different.
Next
month, Team Manager comes with a new opportunity of cycling in a place, new to
both the teams. Both teams explored about place for whatever information they
could get. They give their estimates of distance/complexity/risk ie story
points based on understanding of place by each team. Estimates were different
from both the teams, as their understanding and assumptions of new place, and
understanding of story point in each team is also different. Everyone also
agrees that as it is new place, there can be some surprises which may impact
the velocity.
As
estimates i.e story points were different from both teams, teams decided to
pick items one by one, and start delivering it. If any of the team finish
before their estimation, it can always picks more. Ultimately goal is to
complete the work as Team, while appreciating factor that every team has different
understanding of story points and velocity also.
But
how does it work in overall planning and budgeting for management: Size of team
i.e. capacity is fixed. Manager knows the velocity of team. Any new work is
estimated by team as story points, which divided by velocity gives idea of
tentative timeline.
Isn't
it just tentative, as sprint points are telling the amount of work and not the
time required. Velocity is just the average of amount of work delivered by
team. And that's right. Estimates are meant to be tentative, even if we use
hours.
Why
can't we use hours then
- Relative
vs Absolute: Story points are estimation of amount/complexity/risk of
work, and is relative to other work items. While Hours is a wish to have
absolute value for time required to complete it, in an effort to bring
certainty in estimates.
- Acceptance
of Diversity, Safe Environment: Velocity reflects the team's capacity to
deliver the work. While hours trigger the judgement of individual capacity
to deliver the work. Story points, which are estimates at team level,
accepts inherently that people have different skill set, and experience
which will result in different amount of work. Story point and Velocity at
team level provides an abstraction over this, and creates a safe
environment for team while accepting the diversity.
- Trust in
People over Tracking: Story pointing and velocity based planning also
strengthen trust in team, people. Where we believe that team has best
intention to deliver and will keep picking work as they complete the last
one. Hours triggers the usual tracking routine, with possibility of going
into how many hours were committed, how many have been consumed, who took
more time and why. It is vicious loop, once we slip in that. On other
side, trust empowers and motivate people to deliver more than what one can
think.
Does
that mean that we should not use hours at all - We should leave it to team. If
team is feeling more comfortable talking in term of hours as it can give them
more concrete data at least for immediate work in hand, they can choose to talk
in hours.; However, for distant roadmap, hours always fail the planner. Hence
it is better to go with abstract units, which can inherently reflects the
uncertainty.
Are
story points mandatory for Agile - No. Agile does not talk about estimation
methodology. Agile is philosophy, mindset about doing the work and how team can
operates to maximize the outcome. It is not a framework or set of procedures to
follow.
There
are discussions around #noestimation too. If we combine above points, it is on
similar lines where we build a good team, and then trust team to deliver, and
don't spend time on estimates which always changes. Rather we increase the
frequency of re-planning and adopting to new realities. Team delivers more this
way, rather than by giving estimates, try to stick to estimates by working
overtime or vice versa, and being questioned later with a possible dent on
motivation.
In
agile, (customer) Story matters over anything else, and a trusted team is what
it takes to build the (success) Story.
What
is your story of story points or 'Being Agile'..
Few
good references:
- https://www.ispi-llc.com/blog/2018/8/8/anti-pattern-assigning-story-points-during-backlog-grooming
- https://medium.com/serious-scrum/12-common-mistakes-made-when-using-story-points-f0bb9212d2f7
- https://tech.xing.com/when-story-points-misfire-88b068bfc97c?gi=3972383b8250
0 comments:
Post a Comment