In this video, we'll discuss what is the #NoEstimates movement, how it came into
existence and whether we should consider it while estimating user stories or not.
We will also discuss how to estimate user stories in the story map that
we created in the last video, how to create baseline or reference stories,
an easy to use the bulk estimation technique that I accidentally discovered
while training and Agile team.
And finally, what are some of the common mistakes that teams make
while estimating user stories?
Hey Friends!
Welcome back to the channel.
If you're new here, my name is Vibhor I am an Executive, Agile & Leadership
Coach based in Toronto, Canada.
And this is the 10th video in an ongoing series where I'm trying to simplify the
process of planning an Agile product, starting with product vision followed
by product roadmap release plan,
finally learning how to create product backlogs full of
effective bite-sized user stories.
So if you're a scrum master or an agile coach, you consider subscribing
to learn some actionable and super effective ways to be Agile.
There are time stamps available.
So feel free to skip around the video if you feel like it.
But for now, let's get started.
Estimates have always been an integral part of the software development process.
By estimating the amount of time, money and effort required to reach
project goals and outcomes developers and team leads can help managers and
clients better predict budget and meet project goals and objectives.
At least there's the theory behind the widespread and often unquestioned use
of estimates in the IT industry today.
But should we even be estimating our user stories?
In the year 2012, most popularly known as the year of Armageddon, a
software developer who goes by the name of Woody Zuill, disrupted the
software and Agile community, when he shared a rather inconspicuous blog
post on Twitter and tagged it with the popular, #NoEstimates, hashtag.
That tweet divided the Agile community into two camps.
The camp that thinks that Agile estimates are essential.
And the camp that believes in the opposite.
The #NoEstimates movement led by Zuill himself, gain traction because of the
controversial suggestion he made about eliminating estimates all together.
Zuill used his blogpost to detail the success of a project
completed without estimates.
When faced with a seemingly endless requirements document and asked
for estimates on implementation Zuill and his team took a somewhat
revolutionary, but basic approach.
They identified what they consider to be the most crucial story in
the document, broke that story down into smaller tasks and executed
those tasks as quickly as possible.
Once they showed the client, the initial win in the form of working software,
the client was less concerned with estimates and more willing to let the
development team continue delivering the features out of the to-do list.
Zuill's team shifted their client's focus from estimating time worked
to actually doing the work.
And from projecting costs to cutting costs by simply diving
in and getting down to business.
The #NoEstimates camp made four bold claims.
First estimates are always inaccurate and therefore pointless.
The #NoEstimates camp who believes that when developers are asked to estimate
the amount of time and work required to complete a project, they're asked
to predict the future in a way that can't possibly account for the complex
factors involved in completing the work.
The second bold claim states that estimates are part of the software
development process not because estimates are effective or beneficial, but because
they have been part of the process for so long that developers, managers, and team
leaders assume, that they are a necessity.
The third claim is that developers, often pad estimates with buffers
encouraging mistrust between team members, managers, and clients.
Which can potentially harm project transparency and even damage
healthy working relationships.
The fourth and the last claim is that estimates are a waste of valuable time.
Instead of beginning, the work developers are forced to spend
time and money creating estimates that aren't even accurate to begin
with and are therefore useless.
Now this video is not about #NoEstimates, so I won't go deep into the argument
favoring either Estimates or #NoEstimates.
But just so we have a closure, here's what I think about the whole shenanigan.
As an Agilist, I do not take sides or get attached to ideas that are set in stone.
Now don't take me wrong.
The four claims that I stated earlier do make sense.
But we can't deny the fact that businesses do need estimates, especially in cases
where they need to justify the spending.
For example, the projects that are based on tranche based funding.
At the same time, there are also cases where businesses do not need estimates.
So from an Agile perspective, both extremes, those who say we should never
estimate, and those who say we should always estimate are actually, well
for the lack of better words, WRONG!
These extremes, in my opinion, do not reflect the way the world works.
So instead of arguing whether we should estimate or not, we should find ways that
can help us figure out when we can use estimates to benefit business, and when
we can do without estimates and save time.
For example, in cases where businesses need to figure out the annual budgeting
cycle to allocate money to different projects, estimation makes absolute sense.
It's like going to an online travel site and getting estimates for
various destinations to figure out which travel destination will best
suit the family's travel budget.
You absolutely need that kind of estimation.
On the other hand, in a dynamic market experiencing explosive growth, like
in the case of startups, there may not be much value in estimation because
what they're doing is just releasing functionality as quickly as possible
on very short turnaround cycles.
Now that we have established that we need to be Agile when it comes to estimating
or not estimating user stories, let's see how we can estimate user stories.
If you're following this video series for some time, you know, that I have
touched upon the concept of relative estimation in a previous video on
prioritizing the initial product backlog.
If you haven't already watched that video, a link to it is in the
description or in this corner, if you're watching this on YouTube.
So when it comes to estimating, in Agile we believe in refining our
user story estimates progressively.
Now, if you remember, when we created our initial product backlog and
prioritized it, we used t-shirt sizes to estimate our epics and features.
And this is because at the level of epics and features, we didn't have access to the
more detailed and granular information.
We were still at the ideation level, and therefore we used an
estimation technique that didn't need excessive amounts of information.
We then prioritize the initial product backlog, broke the
features down into smaller user stories, and created a story map.
With each of these steps of redefined user stories, with more details
and a higher level of granularity.
Now we may even have another level of precision beyond this.
For example, during sprint planning, meeting the team breaks
the user stories down into tasks.
So think about estimation as getting progressively refined.
Getting progressively more detailed, getting progressively more precise as more
and more information becomes available.
And the release plan level that we are currently at, we have enough
information to move into what we call the story point estimation.
But before we estimate our user stories, let's see, what are the
prerequisites for story point estimation?
The first prerequisite is the Definition of Done.
For those who are not familiar definition of done or, DoD, as most
people call it is a quality checklist that all user stories of a product,
project, release, or sprint must pass before they could be declared as done.
If you don't currently have a definition of done or stage entry or exit criteria,
as we call it in Kanban, that we can use as a team to decide what kind of
technical practices or quality checks we need before declaring user stories
has done, them, well, you need one.
The definition of done is one of the critical artifacts that
keeps the team producing, working software to high quality standards.
Here are a few things to note about definition of done.
Number one.
Definition of done is exclusive to each development team.
You can't actually copy another team's definition of done.
Number two, definition of done is not the same as acceptance criteria.
Acceptance criteria are specific to each user story, and since it is unique
to a user story, it doesn't transfer to another user story in the backlog.
On the other hand, the definition of done is a single list that applies to
all the user stories without exception.
Here's an example of a definition of done.
The developer has unit tested the functionality.
All acceptance criteria have been met.
Regression tests have been completed and code I've been
reviewed by another developer.
Of course, this is oversimplifying for the sake of education.
Or is it?
The second prerequisite for estimating user stories is having a baseline or a
bunch of reference stories that the team can use as benchmark for new estimates.
So let's see how we, as a scrum masters and agile coaches can help our teams
create a bunch of reference stories.
We'll be using the story map that we created in the last video.
But if you don't have a story map, just use your prioritized product backlog.
Looking at the story map, the first thing you do is ask your team to
select five stories that the whole team can align on, in terms of
complexity, risk and required effort.
You then ask your team to rank the stories on a scale of one to five in
terms of, number one complexity, which includes things like times to research,
analysis, planning, and collaboration or communication required with people outside
the team or with different departments.
The second criterion that feeds rank our stories on is risk or unknowns.
This includes dependencies, rework, fixing defects, incorporating stakeholders
feedback, as well as time spent waiting to be able to do the work.
The third criterion is the effort.
Which, as we all know, is the time required to code
test and validate the code.
Once the team gets busy, ranking the five selected user stories, you
can go and fetch yourself a coffee.
Just kidding.
Or am I?
After the team is done ranking the stories, ask the team to sum the
complexity, risk and effort values for each story and arrange the 5
stories in descending order of the sum, with the larger story at the top.
Something like this.
The next step in creating the reference stories is to look at the ranked stories
in the reference table and assign them a story point using the Fibonacci scale.
To start, we can either pick a middle story for the team and assign
it a five on the Fibonacci scale.
Or we can ask the team to self-organize and pick the middle story themselves.
However, in my experience, I have found that picking a story for the team and
giving them a headstart, especially when the team is new is much easier.
Quicker and less stressful.
Once you have a middle story, you then ask the team to select the next larger story
and assign it a story point, comparing it to the first five point story.
This could be the same five points or a larger number on the Fibonacci scale.
We then do the same with one smaller story and assigning it a story point as well.
Continuing this estimation assignment process will give us
our first five reference stories.
You can have as many different stories as you want.
Five is just what I recommend.
Now that we have our reference stories nicely ranked and
estimated in our reference table.
Let's quickly estimate the rest of the stories in our story map.
Now, if you're familiar with Planning Poker, which by the way, I will cover
in absolute detail in a separate tutorial series on user stories, you
might come to me and say, Vibhor this will take a few days to estimate.
Especially if you have a larger, more complex story map.
Not the one that we are using as an example for educational purposes.
And to that, I would say yes, you're right.
Using planning poker to estimate hundreds of user stories, may take a lot of time.
The good thing, however, is that we don't have to use Planning Poker.
There are many bulk estimation techniques available that we can use to quickly
estimate large number of user stories, or at least a portion of what is
required for the upcoming release.
Let's have a look at one such estimation technique that I accidentally created
while training a team on Affinity Estimation, which is one of the
popular bulk estimation techniques.
The modified Affinity Estimation technique that I created is
called SwimLane Estimation.
And here's how it works.
After I was done recording the whole video, I found that the microphone
died in the middle of the recording.
Now I'll have to go to everything again.
All right.
Let's get back to it.
We use the reference table.
The one that we use to create our reference stories and treat each row
in the reference table as a Swim Lane for different sizes of user stories.
We then ask each team member to silently pick a story from the story
map, one by one, and put it in the appropriate Swim Lane, that they think
is the right size for that story.
The team members can also move stories between swim lanes.
If they believe that the last person didn't put the stories in the right lane.
As scrum masters and agile coaches, we keep an eye on such user stories,
which move more than two times, keeping them separate, so the team can revisit
and discuss them in detail later.
Now, after the team is done, putting all the stories in the proper swim lanes and
done discussing all the controversial user stories, we can use this estimator
story map, to plan our release, which we will discuss in the next video.
Okay.
Now that we have estimated our user stories, that let's take a look at some of
the common mistakes most teams make while estimating user story using story points.
Mistake, number one, converting story points, to hours.
Now I have seen a lot of teams converting story points into hours.
The reason why it is not recommended is that doing so removes the
benefit of relativity, committing everyone to the number of hours,
providing a false sense of accuracy.
Plus it is more challenging to reach a consensus among team members when
aiming for a specific number of hours, versus a range, as in story points.
Mistake, number two, Averaging Estimates.
Now let's say for example, your team members are in disagreement on
estimates for a particular user story.
Half of the team thinks it's a three pointer and the rest
believes that it's an eight.
When this happens, most teams try to meet in the middle to resolve the
conflict and assign the controversial user story, five points, sweeping the
undiscussed details under the rug.
If you, as a scrum master, see this happening, try to encourage
your team to discuss the opposing viewpoints and the outlier estimates.
Letting each person explain the reason for their assessment will
rendered greater clarity and understanding of the work involved.
Mistake, number three, adjusting reference story points every sprint.
When the team adjust referenced stories, every sprint, the velocity of different
sprints is no longer comparable making the team lose the historical
velocity data, which is required to drive continuous process improvement.
Mistake number four, existing story points based on whom it is assigned to.
Now, you may notice from time to time that a user story is a three
pointer for a senior developer and an eight pointer for a junior developer.
Again, if you see this happening, try to get your team assign story
points by comparing the user stories with reference stories.
And not with the level of experience, individuals have.
User story estimation can be a tedious exercise and can be
especially difficult for team members who deal with stakeholders
and executives on a regular basis.
It is therefore essential to understand and make everyone aware
that story points are just estimates.
These can be well-informed estimates, no doubt, but still
they are just best guesses.
Like everything else in the world user story estimation and determining
story points take practice.
Each project and sprint is a chance for the team to learn and improve.
As the accuracy of story points increase over time.
So will your team's productivity and confidence.
So there you have it.
Now that you have an estimated story map, in the following video,
we will finalize our release plan.
Cutting the story map into somewhat realistic Will Haves,
May Haves and Won't Haves.
It'll also be the last video of this tutorial series.
If you like this video, then give it a thumbs up, subscribe,
and don't forget to provide your valuable feedback in the comments.
I'll see you in the next video.