## Re: [scrumdevelopment] Summation of user story points to epic level point estimation

Expand Messages
• ... The answer to the first bit is no. I don t quite understand the second bit.
Message 1 of 10 , Jul 9, 2013
• 0 Attachment
On 10 Jul 2013, at 06:54, "poojawandile" <poojawandile@...> wrote:

> The question is, is it necessary that the point estimation at the user story level should add up to epic point estimation? Or it is OK to have smaller variation in points at epic/story level?

The answer to the first bit is no. I don't quite understand the second bit.
• I think the second bit is just the second of two options: one being have the stories add up to the epic number, which feels very artificial to me, and two
Message 2 of 10 , Jul 9, 2013
• 0 Attachment
I think the second bit is just the second of two options:  one being have the stories add up to the epic number, which feels very artificial to me, and two being there is a difference between the epic estimate and the sum of the stories.

I’m with you Kurt, the answer is no, they don’t need to add up to the epic point estimation.  For that matter, I would trust estimate that did add up like that even less than I already do trust estimates, which is not at all.

Steve
From: Kurt Häusler
Sent: ‎Tuesday‎, ‎July‎ ‎9‎, ‎2013 ‎11‎:‎07‎ ‎PM
To: scrumdevelopment@yahoogroups.com

On 10 Jul 2013, at 06:54, "poojawandile" <poojawandile@...> wrote:

> The question is, is it necessary that the point estimation at the user story level should add up to epic point estimation? Or it is OK to have smaller variation in points at epic/story level?

The answer to the first bit is no. I don't quite understand the second bit.

• Hi Pooja, it s ok for the math to not fit in these cases. Keep in mind that a large epic is more vague to plan with. Smaller user stories that fit into a
Message 3 of 10 , Jul 10, 2013
• 0 Attachment
Hi Pooja,

it's ok for the math to not fit in these cases. Keep in mind that a large epic is more vague to plan with. Smaller user stories that fit into a sprint for a particular epic might be less or more than the original estimated points for the epics. Statistically they will balance out in the long run.

Best Markus

--
Dipl.-Inform. Markus Gärtner
Author of ATDD by Example - A Practical Guide to Acceptance
Test-Driven Development

On 10.07.2013, at 06:54, "poojawandile" <poojawandile@...> wrote:

HI,
During one of our discussions, the point related to story point estimation at epic and user story level came up. During release planning, the product owner usually define Epics which are then further sliced into smaller user stories at the product backlog grooming meetings. The epics are normally large in size and estimated at 13 points and above and the stories are sliced such that each story is not more than 8 points. Each epic can have multiple user stories. The question is, is it necessary that the point estimation at the user story level should add up to epic point estimation? Or it is OK to have smaller variation in points at epic/story level?

Regards,
Pooja

------------------------------------

To Post a message, send it to:   scrumdevelopment@...
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links

<*> To visit your group on the web, go to:

<*> To change settings online go to:

(Yahoo! ID required)

<*> To change settings via email:

<*> To unsubscribe from this group, send an email to:

<*> Your use of Yahoo! Groups is subject to:

• In the little experience that I have working with the teams for better estimations. Trying to use the same measure across different levels of always seems to
Message 4 of 10 , Jul 10, 2013
• 0 Attachment
In the little experience that I have working with the teams for better estimations. Trying to use the same measure across different levels of always seems to create similar confusions

What we have tried to do for some of our teams to have separate notion of relative estimations at Epic(epic points) and Story(story points) levels. This has helped the POs most as they can still track the progress and give a high level release plan without pushing the teams to estimate early or trying to superimpose estimations at higher level to better estimations done by team at story level

With Regards,
Chair, India Scrum Enthusiasts Community (ISEC)
Founder, Agile Pune

Call: +91.8506011150

On 10 July 2013 10:24, poojawandile wrote:

HI,
During one of our discussions, the point related to story point estimation at epic and user story level came up. During release planning, the product owner usually define Epics which are then further sliced into smaller user stories at the product backlog grooming meetings. The epics are normally large in size and estimated at 13 points and above and the stories are sliced such that each story is not more than 8 points. Each epic can have multiple user stories. The question is, is it necessary that the point estimation at the user story level should add up to epic point estimation? Or it is OK to have smaller variation in points at epic/story level?

Regards,
Pooja

• Story points are relative measures. Expecting Epic=Σ Stories is making them absolute measures. Stories are not arithmetic decomposition of epics. Most often
Message 5 of 10 , Jul 10, 2013
• 0 Attachment

Story points are relative measures. Expecting Epic=Σ Stories is making them absolute measures. Stories are not arithmetic decomposition of epics. Most often than not, there will be difference between the epic size and sum of story points.
Prashant Pund
Agile Coach
AgileSoft Methodologies

On Jul 10, 2013 12:44 PM, "Markus Gärtner" <mgaertne@...> wrote:

Hi Pooja,

it's ok for the math to not fit in these cases. Keep in mind that a large epic is more vague to plan with. Smaller user stories that fit into a sprint for a particular epic might be less or more than the original estimated points for the epics. Statistically they will balance out in the long run.

Best Markus

--
Dipl.-Inform. Markus Gärtner
Author of ATDD by Example - A Practical Guide to Acceptance
Test-Driven Development

On 10.07.2013, at 06:54, "poojawandile" <poojawandile@...> wrote:

HI,
During one of our discussions, the point related to story point estimation at epic and user story level came up. During release planning, the product owner usually define Epics which are then further sliced into smaller user stories at the product backlog grooming meetings. The epics are normally large in size and estimated at 13 points and above and the stories are sliced such that each story is not more than 8 points. Each epic can have multiple user stories. The question is, is it necessary that the point estimation at the user story level should add up to epic point estimation? Or it is OK to have smaller variation in points at epic/story level?

Regards,
Pooja

------------------------------------

To Post a message, send it to:   scrumdevelopment@...
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links

<*> To visit your group on the web, go to:

<*> To change settings online go to:

(Yahoo! ID required)

<*> To change settings via email:

<*> To unsubscribe from this group, send an email to:

<*> Your use of Yahoo! Groups is subject to:

• Madhur, Can you please give more insights on this estimation ? Thanks Sekhar On Wed, Jul 10, 2013 at 12:55 PM, Madhur Kathuria
Message 6 of 10 , Jul 10, 2013
• 0 Attachment

Can you please give more insights on this estimation ?

Thanks
Sekhar

On Wed, Jul 10, 2013 at 12:55 PM, Madhur Kathuria wrote:

In the little experience that I have working with the teams for better estimations. Trying to use the same measure across different levels of always seems to create similar confusions

What we have tried to do for some of our teams to have separate notion of relative estimations at Epic(epic points) and Story(story points) levels. This has helped the POs most as they can still track the progress and give a high level release plan without pushing the teams to estimate early or trying to superimpose estimations at higher level to better estimations done by team at story level

With Regards,
Chair, India Scrum Enthusiasts Community (ISEC)
Founder, Agile Pune

On 10 July 2013 10:24, poojawandile wrote:

HI,
During one of our discussions, the point related to story point estimation at epic and user story level came up. During release planning, the product owner usually define Epics which are then further sliced into smaller user stories at the product backlog grooming meetings. The epics are normally large in size and estimated at 13 points and above and the stories are sliced such that each story is not more than 8 points. Each epic can have multiple user stories. The question is, is it necessary that the point estimation at the user story level should add up to epic point estimation? Or it is OK to have smaller variation in points at epic/story level?

Regards,
Pooja

• Pooja, ... To further what others have said, I suggest not even using the same point scale for your epics and your small stories. Before refining the epics
Message 7 of 10 , Jul 10, 2013
• 0 Attachment
Pooja,

On 7/10/13 12:54 AM, poojawandile wrote:
> HI,
> During one of our discussions, the point related to story point
> estimation at epic and user story level came up. During release
> planning, the product owner usually define Epics which are then
> further sliced into smaller user stories at the product backlog
> grooming meetings. The epics are normally large in size and estimated
> at 13 points and above and the stories are sliced such that each
> story is not more than 8 points. Each epic can have multiple user
> stories. The question is, is it necessary that the point estimation
> at the user story level should add up to epic point estimation? Or it
> is OK to have smaller variation in points at epic/story level?

To further what others have said, I suggest not even using the same
point scale for your epics and your small stories. Before refining the
epics into stories, there is no mathematical precision to them.

I prefer using T-shirt sizes (small, medium, large) for epics so that
people are less tempted to do math on the unknown. Over time, you can
collect data on how many story points were actually completed for
various size epics. This will give you numerical ranges for plotting
predictions. (See
http://blog.gdinwiddie.com/2010/04/22/projecting-into-the-future/)
You're not tied to a particular number, though, and if you see that the
size of a "medium" has drifted over time, you can project with what you
feel is the more realistic range.

- George

--
Want to speak at AgileDC October 8, 2013? http://agiledc.org/speak/
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------
• Resist strongly the urge to do anything involving story-point math. Story-point math is a smell that you re missing the point. Story-points (and estimates in
Message 8 of 10 , Jul 10, 2013
• 0 Attachment
Resist strongly the urge to do anything involving story-point math.  Story-point math is a smell that you're missing the point.

Story-points (and estimates in general) are a somewhat useful tool for selecting the right amount of work to put into a Sprint.  They also have some utility for getting a ballpark idea of how many Sprints an epic might take.  But this idea breaks down the bigger an epic gets - kind of a Hiesenberg Uncertainty Principle for Scrum  and when you get past that point you're virtually doing Waterfall again.

What I would expect to see happen, if everything is proceeding normally, is that the number of User Stories that made up an epic would change over the course of working on an epic and that the estimates for many of those User Stories would also change.  This would reflect the feedback that the both the programmers and the users are putting into the backlog as they project progresses, and if it doesn't happen, then you're probably doing something wrong.

So the idea of adding up the story-points in the constituent parts of an epic and comparing them to the story points assigned to the epic is probably only feasible in a really small epic, but in that case the "big picture" planning aspect about the epic (ie:  is it going to take 6 Sprints or 10 Sprints to finish?) is negligible.

Dave Barrett

This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please delete it and advise me (by return e-mail or otherwise) immediately.

Ce courrier électronique est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite. Si vous recevez ce courrier électronique par erreur, veuillez le supprimer et m'en aviser immédiatement, par retour de courrier électronique ou par un autre moyen.
• ... Story-point math is a smell that you re missing the point. ... Absolutely. The main problem with story points is that they are a pseudo-mathematical
Message 9 of 10 , Jul 10, 2013
• 0 Attachment

On Jul 10, 2013 3:28 PM, "David A Barrett" <dave.barrett@...> wrote:
>
>
>
> Resist strongly the urge to do anything involving story-point math.  Story-point math is a smell that you're missing the point.
>

Absolutely. The main problem with story points is that they are a pseudo-mathematical concept that for some reason encourages people to compound estimation errors with elaborate arithmetic.

The other problem with story points is that for some reason they enable people to accept stories that are larger than the smallest valuable slice they are capable of delivering.

Your message has been successfully submitted and would be delivered to recipients shortly.