Jaowoefhcnmacnc
Ascjascncvlkascksc
Mksvklsvnasascm
entire team understand the work more fully. For product owners
specifically, breaking down work items into granular pieces and estimates
via story points helps them prioritize all (and potentially hidden!) areas of
work. And once they have estimates from the dev team, it's not
uncommon for a product owner to reorder items on the backlog.
Agile story points estimation is a team sport
Involving everyone (developers, designers, testers, deployers... everyone)
on the team is key. Each team member brings a different perspective on
the product and the work required to deliver a user story. For example, if
product management wants to do something that seems simple, like
support a new web browser, development and QA need to weigh in
because their experience has taught them what dragons may be lurking
beneath the surface.
Likewise, design changes require not only the design team's input, but
that of development and QA as well. Leaving part of the broader product
team out of the estimation process creates lower quality estimates, lowers
morale because key contributors don't feel included, and compromises
the quality of the software.
So don’t let your team fall victim to estimates made in a vacuum. It’s a
fast track to failure!
Want to give story points a try? First, sign up or log into Jira
Try this interactive tutorial to set up your first scrum project
Learn how to configure story point estimations and track your user stories
Story points vs. hours
Traditional software teams give estimates in a time format: days, weeks,
months. Many agile teams, however, have transitioned to story points.
Story points are units of measure for expressing an estimate of the overall
effort required to fully implement a product backlog item or any other
piece of work. Teams assign story points relative to work complexity, the
amount of work, and risk or uncertainty. Values are assigned to more
effectively break down work into smaller pieces, so they can address
uncertainty. Over time, this helps teams understand how much they can
achieve in a period of time and builds consensus and commitment to the
solution. It may sound counter-intuitive, but this abstraction is actually
helpful because it pushes the team to make tougher decisions around the
difficulty of work. Here are few reasons to use story points:
Dates don’t account for the non-project related work that inevitably
creeps into our days: emails, meetings, and interviews that a team
member may be involved in.
Dates have an emotional attachment to them. Relative estimation
removes the emotional attachment.
Each team will estimate work on a slightly different scale, which means
their velocity (measured in points) will naturally be different. This, in turn,
makes it impossible to play politics using velocity as a weapon.
Once you agree on the relative effort of each story point value, you can
assign points quickly without much debate.
Story points reward team members for solving problems based on
difficulty, not time spent. This keeps team members focused on shipping
value, not spending time.
Unfortunately, story points are often misused. Story points go wrong when
they’re used to judge people, assign detailed timelines and resources, and
when they’re mistaken for a measure of productivity. Instead, teams
should use story points to understand the size of the work and the
prioritization of the work. For an in-depth discussion on story points and
estimation practices, check out this roundtable with industry experts, and
read on for more agile estimation tips.
Story points and planning poker
Teams starting out with story points use an exercise called planning
poker. At Atlassian, planning poker is a common practice across the
company. The team will take an item from the backlog, discuss it briefly,
and each member will mentally formulate an estimate. Then everyone
holds up a card with the number that reflects their estimate. If everyone is
in agreement, great! If not, take some time (but not too much time–just
couple minutes) to understand the rationale behind different estimates.
Remember though, estimation should be a high level activity. If the team
is too far into the weeds, take a breath, and up-level the discussion.
Ready to give it a try?
Install this Planning Poker App
Learn more about Planning Poker
Keep estimations high level. If the team is too far into the weeds, take a
breath, and up-level the discussion. #AgileTips
Estimate smarter, not harder
No individual task should be more than 16 hours of work. (If you're using
story points, you may decide that, say, 20 points is the upper limit.) It’s
simply too hard to estimate individual work items larger than that with a
high degree of confidence. And that confidence is especially important for
items at the top of the backlog. When something is estimated above your
team's 16-hour (or 20-point) threshold, that's a signal to break it down
into more granular pieces and re-estimate.
For items deeper in the backlog, give a rough estimate. By the time the
team actually begins to work on those items, the requirements may
change, and your application certainly will have changed. So prior
estimates won’t be as accurate. Don’t waste time estimating work that is
likely to shift. Just give the product owner a ballpark figure she can use to
prioritize the product roadmap appropriately.
Learn from past estimates
Retrospectives are a time for the team to incorporate insights from past
iterations–including the accuracy of their estimates. Many agile tools
(like Jira) track story points, which makes reflecting on and re-calibrating
estimates a lot easier. Try, for example, pulling up the last 5 user stories
the team delivered with the story point value 8. Discuss whether each of
those work items had a similar level of effort. If not, discuss why. Use that
insight in future estimation discussions.
Like everything else in agile, estimation is a practice. You'll get better and
better with time.
Related resources
Project Management Resources
Project Planning Resources
Product Launch Resources
Project Management Go-To-Market Strategies
Resource Management Resources
Task-Tracking Resources
Software Project Management
SHARE THIS ARTICLE
DAN RADIGAN
Agile has had a huge impact on me both professionally and personally as
I've learned the best experiences are agile, both in code and in life. You'll
often find me at the intersection of technology, photography, and
motorcycling.
Try story points for free in Jira
Sign up now
SUBSCRIBE
Sign up for more articles
Email
Subscribe
TUTORIAL
Learn burndown charts with Jira
The go-to-guide for burndown charts in Jira. Learn how to monitor epics
and sprints with burndown charts.
Try this tutorial
ARTICLE
Five agile metrics you won't hate
How to use agile metrics. Learn about sprint burndown, epic and release
burndown, velocity, control charts & the cumulative flow diagram.
Read this article
