A Word About Size Metrics User Story Defined

• Very few software development projects start without • A User Story is a simple statement about what a user wants to do
some concept/metric of how long and how much time with a feature and the value the user will gain.

the development will take • Consider a User Story as a thin vertical slice through the system.

• The Estimator's challenge is to "quiz" that out of the • User stories are written from the user perspective in a way that
can be easily understood.
metric • Technical jargon is avoided.
• I have always felt more confident in my answer when • Acceptance Criteria is usually written at the same time.
the estimation team's size metric/proxy and the • The Project Owner is responsible for the user stories
development team's effort proxy were the same
• Written by the Sponsor
• I believe there is more estimation error from poor • Reviewed by the project team
sizing than from estimation models or processes • Usually written on cards
• The fact that this is a briefing about User • Story on the front
Stories/Story Points in no way a critique of Lines of • Acceptance Criteria on the back
Code or Function Points or any other size metric

© 2015 Copyright Galorath Incorporated 1 © 2015 Copyright Galorath Incorporated 2

1 2

Anatomy of a User Story Writing User Stories On An Agile Project

• A User Story identifies: • User Stories are owned by the Product Owner

• The User • Written by the Product Owner or a surrogate of the Product Owner
such as a Business Analyst.
• What the user wants to do with a feature
• The product owner ultimately approves the User Story.
• Value gained by the user
• User Stories are written from feature lists with the intention of
• So a User Story can use the following format: filling the product backlog.

As a (user role) • This is often done in iteration zero

• Before placing a User Story in the backlog, the story is reviewed,
I want (feature/achieve something) acceptance criteria is written, and the story is pointed.
So that (describe value) • The Team, with the help of the Product Owner, selects User
Stories from the project backlog for an iteration.
• This is part of iteration planning.
• As a customer I want to track my order from the time I
place it until it is delivered so that I know the status of my
order at all times.

© 2015 Copyright Galorath Incorporated 3 © 2015 Copyright Galorath Incorporated 4

3 4

User Stories And Other Requirements Bad User Story

• As mentioned previously, User Stories are requirements, but As an AR Clerk I can add invoices to the system
sometime more information is needed.
• Since you want to keep User Stories light and negotiable, you
may have to supplement them with information as the story What’s wrong:
progresses.
• Other types of requirements include:
• No value shown. The value may imply other things we
will want to do with an invoice.
• Business rules
• Regulations
• More detail Better:
• Consider referencing these requirements on the bottom of the • As an AR Clerk I want to add invoices in the system so
User Story card.
that I can easily view the invoice when needed.
• This implies that that we must be able to view invoices
in the AR system.

© 2015 Copyright Galorath Incorporated 5 © 2015 Copyright Galorath Incorporated 6

5 6

1
 Story Points Rate The Following From 1 - 10

• A "User Story" is a simple statement about what a user • Simply give each dog a value between 1 and 10. 1 is least
wants to do with a feature and the value the user will gain and 10 is most. Numbers can be repeated
from that feature. • Don’t over think the question
• A "Story Point" is a methodology to assess the relative
weight/effort level of a User Story

• NOTE 1 - Some would say that User Stories and Story

Points are project and developer unique and therefore NOT
transferable to other projects. And, there is some truth to
that statement.
• NOTE 2 – The modern "cynic" might say the same thing for
SLOC and Function Points
• At this time there is little standardization associated with
User Stories or Story Points so be careful when drawing
inferences beyond a specific program.

© 2015 Copyright Galorath Incorporated 7 © 2015 Copyright Galorath Incorporated 8

7 8

Try The Exercise Again Using One Of

Story Points Defined
The Following Assumptions
• How long will it take to Groom the dog? • Story Points represent a value given to a
• How fast can it run? user story that is used to measure the effort
required to implement the story.
• How much does it weigh?
• Points are assigned to User Stories
• Those point values are later used to estimate
• It is a number that represents story size based
on how hard a story is to implement.
• When assigning points to a story focus is placed
on effort to implement but not on time. That
comes later during estimation.
• Many would say that a story point is an arbitrary
measurement that depends on the team.
• There is some truth to that statement
• We can manage that to some extent
© 2015 Copyright Galorath Incorporated 9 © 2015 Copyright Galorath Incorporated 10

9 10

Most Likely… The Answer Changed How Much Effort Is Required?

• The exercise that was just performed is exactly how story • Look at other things surrounding the implementation of
points work the story. Especially architectural maturity
Note: We are leaving puppies behind and will consider the item
• One story may look complex but all the infrastructure is
to size is a “User Story”
already in place or understood
• When sizing User Stories with Story Points one must
• Another may require creating a whole new piece of the
consider many things. For example:
architecture where there is a lot that is not understood
• How complex is the User Story (number of skills that may be
needed) • Of course not understanding is fine because we
prototype. But it still can be included in how hard a story
• How much functionality already exists (and does not need to
may be
be design/coded/tested)

• How does it compare to similar User Stories (scale)

• Is it too big a story to properly try to size

• The goal is to understand how much “Effort” is required

© 2015 Copyright Galorath Incorporated 11 © 2015 Copyright Galorath Incorporated 12

11 12

2
 Things To Consider When Counting SPs Some Drawbacks To Story Points

• Number of interfaces with the outside world • Story Points are team dependent!
• Most agile teams do not function in a vacuum and must • Members of different teams will have different levels of
consider the needs of the rest of the organization. experience leading to different perspectives related to how
• Certain tasks and artifacts may be required by the hard a story is.
organization or by governance that the team will have to
support. • Points don’t easily scale across different projects.
• This could vary depending on the story or the product. • How one team’s points can vary.

• Complexity of the Code • "Inflation" can occur as soon as the second sprint
• Number of required tasks • Teams often blame not delivering the Story due to a faulty
• Depending on the story certain formal or informal tasks may count. That is usually not the reason!
not be necessary. • As a consequence a natural inflation appears during the next
• Regulation can play into this count.
• There may be more checks and balances to a story due to governance

• Coordinating people takes effort too

© 2015 Copyright Galorath Incorporated 13 © 2015 Copyright Galorath Incorporated 14

13 14

Steps In Pointing Stories Choosing A Pointing System

• Start with a point system that everyone agrees on. • Most pointing sequences are chosen at the organization
• It is best that the system used to compare against is used across level and used by all agile projects.
projects just for consistency.
• The most common sequence is the Fibonacci Series which
• Identify at least one base story. is: 1, 2, 3, 5, 8, 13, 21, 34, 55…
• It could be a medium or average size story but it doesn’t have to be.
• Many teams use a version of Fibonacci that looks like: 1, 2,
• This base story will be used to compare other stories against.
3, 5, 8, 13, 40, 100 (this is what SEER does)
• Review each story as a team.
• The reasoning for using this is that the original sequence
• Discuss its complexity and size considering what it will take to suggests accuracy and real projects at a close precision
develop the story.
• This gives the team a clear choice to differentiate for large
• Compare the story against the base story and agree on a score for
stories.
the story selecting a number in the sequence being used.
• There isn’t much different between 13 and 14 or 15, but there is a different
• The team must agree unanimously on a score between 13 and 21. We can see the difference.
• You can use games to determine score.

© 2015 Copyright Galorath Incorporated 15 © 2015 Copyright Galorath Incorporated 16

15 16

A Process For Assigning Points Exercise: Planning Poker Exercise

• Review a group of stories as a teams • Each team member gets a deck of Planning Poker Cards
• Discuss the complexity of the story and the activities that will • Assign one team member as the Scrum Master to read the
be needed to implement the story. story out loud and negotiate a consensus
• Consider unknown technology and new processes required.
• Each person selects a card representing the points they
• Each team member selects a number from their Planning want to assign but do not let anyone else see it.
Poker deck of cards
• Everyone exposes their card when directed by the Scrum
• The team discusses until they agree on a point value. Master
• If the team can’t agree, the story is sent back to the Product
Owner to be rewritten.
• If everyone has the same number the story is assigned the
points chosen.
• If a story point cannot be agreed upon the problem usually
resides in the story itself. • If not, the people with the lowest and highest point value
explain reasoning for their point selection.
• Re-voting takes place and is repeated until everyone
agrees.
• The following slide contains four easy User Stories

© 2015 Copyright Galorath Incorporated 17 © 2015 Copyright Galorath Incorporated 18

17 18

3
 Story Point Velocity And Why Should I Care About Velocity?

• Velocity measures how much of something can be achieved • Velocity Measure provides a way to translate a Size into a
over a fixed period of time; e.g. how many Story Points are duration
completed during a Sprint
• Every estimate starts with a Size estimate (Lines of Code,
• You could do this at the User Story level but you have no relative Function Points, Use Case Points, Ideal Days, Story Points,
measure between User Stories Hot Dogs in a bucket!)
• Velocity is a “team” measurement – not the individual
• Iteration Duration / Completed Total SP = Velocity • Size / Velocity = Duration
• Iterations needed = Total SP / Velocity
• Don’t change the duration and use the same result • Every estimation process requires a relationship between a
volume measure (Size) and productivity – how much size
can be done over time
Quiz: A project has a total size of 365 Story Points. The team
has a velocity of 25/SP per iteration • Velocity can be sued as a TEAM productivity measure.
How many iterations will the project take?

© 2015 Copyright Galorath Incorporated 19 © 2015 Copyright Galorath Incorporated 20

19 20

Story Points Velocity Can Be Used to

Advantages To Story Points (a few)
Determine Duration/Iterations
• Prevents Managers from converting a SP into a Calendar
• What does the customer want…. A Schedule! day (They have to know the velocity)
• But to provide one you need to know the teams Story • Promotes cross-functional behavior (teams can compare
Point “velocity” similar things)
• If the schedule is too long then some functionality could be • Points do not decay (when compared to ideal days)
removed – or other adjustments made
• They are a “Pure” size measure relative to other known
things
• People are pretty good at generating a valid relationship of
size

© 2015 Copyright Galorath Incorporated 21 © 2015 Copyright Galorath Incorporated 22

21 22

Disadvantages Galorath Contacts

• Difficult to explain QUESTIONS

• May resort to comparing Poodles to Great Danes
• Teams have different interpretations when working
independently Dan Galorath, 310-414-3222 ex 61; [email protected]
• Story Points need to be scored as a team Bob Hunt, 703-201-0651; [email protected]

• Tendency to skip over detailed iteration planning by David DeWitt,321-848-3410; [email protected]

assuming a velocity * SP = work
• Still need to break the User Story into tasks and estimate the
capacity for the sprint

• Takes a while to trust the results

• But this is common for all new sizing measures!

© 2015 Copyright Galorath Incorporated 23

23 24