domaduma2

HdbJDQWD LQWM CWKM.MDM.WQm n,nd,cvc.
dm
the ordered list of work that contains short descriptions of all desired
features and fixes for a product. Product owners
capture requirements from the business, but they don’t always
understand the details of implementation. So good estimation can give
the product owner new insight into the level of effort for each work item,
which then feeds back into their assessment of each item's relative
priority.
When the engineering team begins its estimation process, questions
usually arise about requirements and user stories. And that's good: those
questions help the 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

domaduma2

Uploaded by

Copyright:

Available Formats

domaduma2

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

domaduma2

Uploaded by

Copyright:

Available Formats

HdbJDQWD LQWM CWKM.MDM.WQm n,nd,cvc.

Agile story points estimation is a team sport

Learn from past estimates

Try story points for free in Jira

Try this tutorial

Read this article

You might also like