What is a story point and what is it good for?
Michael de la Maza
the map. I know because I went looking.
Maybe a story point is a nebulous unit of time: "Story points
represent nebulous units of time."[7]
Maybe a story point measures effort: "Story point is a random measure
used by Scrum teams. This is used to measure the effort required to
implement a story." [1]
Does a story point measure size and complexity? "So, points are
relative measurements of size/complexity, not absolute measurements of
duration."[2]
Or perhaps a story point is many things: "...a story point estimate is
an amalgamation of effort involved in developing the feature, the
complexity of developing it, the risk inherent in it, and so on."[13]
How are story points used? Again, opinions differ wildly.
Maybe the number of story points in a sprint (velocity) is a measure
of productivity: "Truth be told velocity really is a productivity
measure..."[8]
Maybe story points should not be used to measure productivity: "Using
story points or ideal days to measure productivity is a bad idea
because it will lead the team to gradually inflate the meaning of a
point..."[4]
Maybe story points should be burned down during a sprint: "Basic
Truths about HyperProductive Scrum...Burn down Story points only"[6]
Or maybe it’s the other way around and story points should not be
burned down during a sprint: "I also recommend estimating the sprint
backlog in hours rather than in points."[3]
When it comes to story points, it’s a wild rumpus of opinion. Some
writers believe that teams achieve steady state velocity[9], others do
not[10]. Some believe that there is a mapping between story points
and time[11], while others do not[12].
When I started writing this note, I hoped to answer the question in
the title. After doing this research, I confess, I can’t tell any
more what a story point is or what it is good for.
I now think that story points and associated practices (like burndown
charts or poker planning) conflate so many intellectually distinct
ideas and goals, from increasing shared understanding to avoiding
gaming, that I am searching for a new way to describe them and
introduce them to people who are new to Scrum.
The Scrum Guide[5] does not mention story points at all -- that may be
the best way to go.
References
[1] http://agilefaq.net/2007/11/13/what-is-a-story-point/
[2] http://en.wikipedia.org/wiki/Story_points
[3] http://blog.mountaingoatsoftware.com/why-i-dont-use-story-points-for-sprint-planning
[4] http://blog.mountaingoatsoftware.com/should-companies-measure-productivity-in-story-points-ideal-days
[5] http://www.scrum.org/storage/scrumguides/Scrum%20Guide.pdf#view=fit
[6] Sutherland, Jeff. "Practical Roadmap to Great Scrum:
Systematically Achieving Hyperproductivity."
[7] Khanal, Samir. "Function point vs. Story point." See
http://c2.com/cgi/wiki?NebulousUnitOfTime for the definition.
[8] https://www.ibm.com/developerworks/mydeveloperworks/blogs/ambler/entry/metric_acceleration?lang=en
[9] http://agilesoftwaredevelopment.com/blog/jackmilunsky/significance-story-points
[10] http://agilethinking.net/blog/2007/05/21/estimation-time-or-size/
[11] http://blog.mountaingoatsoftware.com/how-do-story-points-relate-to-hours
(Mike Cohn's post)
[12] http://blog.mountaingoatsoftware.com/how-do-story-points-relate-to-hours
(Giora Morein's response); http://radio.javaranch.com/lasse/2008/04/17/1208381586654.html
[13] Cohn, Mike. Agile Estimating & Planning.
=================
Learn about the Dialogue Room at the 2010 Orlando Scrum Gathering:
http://scrumgathering2010us.posterous.com/
Sign up to be a doctor at the Scrum Clinic:
http://spreadsheets.google.com/viewform?hl=en&formkey=dDBMeVdEUk1UN2lTZWJ0SHFUY0FYNmc6MA
Sign up to be a patient at the Scrum Clinic:
http://spreadsheets.google.com/viewform?hl=en&formkey=dFdxX1J2YzJ2b1I5XzVsYlREa0E4RHc6MA
Dan Rawsthorne
1. A Story is both a requirement and an activity. So a SP could
logically be used to measure the size of a requirement (like a Function
Point does, or like Complexity does) and it could also measure the size
of an activity (a unit of effort, like Hours). Usually we want it to do
both, so confusion is inherent.
2. A Team usually WANTS Velocity to be a productivity metric in order to
talk to the outside world about "how fast" it is. I note that Velocity
is calculated in two basic ways. The original way is Velocity = (done
SPs)/Sprint, but Ken Schwaber is now using Velocity = (done SPs)/$100K.
2a (side comment) BTW, these are two different metrics, and are
equivalent to using Earned Value's CPI and SPI metrics. When talking to
people that know that stuff, I compare talking about SPs as the "same
problem" as talking about Function Points. The FP folks have been
wrestling with these issues for 30 years, but we (in the agile
community) are just now discovering them.
3. For Velocity to be a meaningful metric (nomatter how you define it),
the SPs should NOT change size; that is, the size of a Story (as a
requirement) doesn't change with time. If SPs represent effort, they
DOchange size as the Team gets better (or the Technical Debt gets
worse), and this leads to what I have referred to in the past as the
"Alan Atlas conundrum" - that a team can get "better" but the Velocity
doesn't go up.
4. To do this (make SPs be the same size), the "baseline story" all
stories are compared to (with planning poker) must remain consistent.
Remember the "how big is THIS story compared to THAT story?" question...
and I note that if this is done, and the baseline story is not only
consistent within a Team, but across Teams, then Velocity not only
measures productivity, but can also be meaningfully compared across
Teams, and is additive within an organization (my Org produced XXX SPs
last SPrint, etc). BTW, this discussion starts good arguments...
5. Once SPs are defined this way, then they become useful for Release
Planning. As a team matures, and its development process reaches "steady
state", its Velocity will become consistent (Law of Large Numbers,
Central Limit Theorem, etc). Of course, we expect its Velocity to be
variable (probably lower, but maybe higher if it is improving its "def'n
of done" across time) until it reaches steady state (when it is
performing, and its process is fixed...). This implies that SPs for
Release Planning are "better" if a Team is allowed to reach "steady
state" and stay there - so good luck with that, all you guys that create
matrixed teams every time :)
6. But... for the insides of the Team, SPs don't matter - what matters
is the "defn of done". A Team doesn't need to know its own productivity,
it just needs to know that it's getting things "done". Velocity is only
useful as a way of talking between the PO and the Stakeholders. Inside
the Team we talk about "done" and burn down different things (usually).
This also starts good arguments...
7. I note that Ron recommends making all the Stories about the "same
size" and then just counting the Stories, and using the count as the
Velocity. This is a great idea, and changes the issue from being one of
guessing what SPs are to one of making the Stories all the "same size".
Maybe this is easier for the Team, especially in some domains. However,
doing this makes it unlikely that Velocities can be compared across
Teams - and it may make it difficult to compare across time, as well -
until the Team reaches "steady state" on its production of "same size"
stories, at least.
8. Enough! Talking about Story Points is a fun exercise, isnt' it? And,
as you've noted, it's not part of Scrum.
Dan ;-)
Dan Rawsthorne, PhD, CST
Senior Coach, Danube Technologies
d...@danube.com, 425-269-8628
Michael de la Maza wrote:
> What exactly is a story point? Answers to this question are all over
> the map. I know because I went looking.
>
> Maybe a story point is a nebulous unit of time: "Story points
> represent nebulous units of time."[7]
>
> Maybe a story point measures effort: "Story point is a random measure
> used by Scrum teams. This is used to measure the effort required to
> implement a story." [1]
>
> Does a story point measure size and complexity? "So, points are
> relative measurements of size/complexity, not absolute measurements of
> duration."[2]
>
> Or perhaps a story point is many things: "...a story point estimate is
> an amalgamation of effort involved in developing the feature, the
> complexity of developing it, the risk inherent in it, and so on."[13]
>
> How are story points used? Again, opinions differ wildly.
>
> Maybe the number of story points in a sprint (velocity) is a measure
> of productivity: "Truth be told velocity really is a productivity
> measure..."[8]
>
> Maybe story points should not be used to measure productivity: "Using
> story points or ideal days to measure productivity is a bad idea
> because it will lead the team to gradually inflate the meaning of a
> point..."[4]
>
> Maybe story points should be burned down during a sprint: "Basic
> Truths about HyperProductive Scrum...Burn down Story points only"[6]
>
> Or maybe it�s the other way around and story points should not be
> burned down during a sprint: "I also recommend estimating the sprint
> backlog in hours rather than in points."[3]
>
> When it comes to story points, it�s a wild rumpus of opinion. Some
> writers believe that teams achieve steady state velocity[9], others do
> not[10]. Some believe that there is a mapping between story points
> and time[11], while others do not[12].
>
> When I started writing this note, I hoped to answer the question in
> the title. After doing this research, I confess, I can�t tell any
reynaldo bendijo
Dan Rawsthorne <d...@danube.com> wrote:
>> Or maybe it’s the other way around and story points should not be
>> burned down during a sprint: "I also recommend estimating the sprint
>> backlog in hours rather than in points."[3]
>>
>> When it comes to story points, it’s a wild rumpus of opinion. Some
>> writers believe that teams achieve steady state velocity[9], others do
>> not[10]. Some believe that there is a mapping between story points
>> and time[11], while others do not[12].
>>
>> When I started writing this note, I hoped to answer the question in
>> the title. After doing this research, I confess, I can’t tell any
>--
>You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
>To post to this group, send email to scruma...@googlegroups.com.
>To unsubscribe from this group, send email to scrumallianc...@googlegroups.com.
>For more options, visit this group at http://groups.google.com/group/scrumalliance?hl=en.
>
Ron Jeffries
wrote:
> I now think that story points and associated practices (like burndown
> charts or poker planning) conflate so many intellectually distinct
> ideas and goals, from increasing shared understanding to avoiding
> gaming, that I am searching for a new way to describe them and
> introduce them to people who are new to Scrum.
Story points are a relative measure of the time needed to implement
a story, borrowed from XP (as is the notion of story). They are
intended to be a way of estimating difficulty without committing to
a specific time duration, so that variances in team size or time on
task do not affect them. They are now thought by some experts, and
by me, to be unnecessary.
You see all kinds of contradictions in what you write below. I see
the same things being expressed in different ways.
> Maybe a story point is a nebulous unit of time: "Story points
> represent nebulous units of time."[7]
Yes, they can be thought of as "proportional" to time, given some
assumptions about team and individual capability and time on task.
>
> Maybe a story point measures effort: "Story point is a random measure
> used by Scrum teams. This is used to measure the effort required to
> implement a story." [1]
Yes, they measure effort.
>
> Does a story point measure size and complexity? "So, points are
> relative measurements of size/complexity, not absolute measurements of
> duration."[2]
Yes, they measure size and complexity. The terms "size" and
"complexity" are used to mean "how hard is this in terms of how long
it'll take us to do it".
>
> Or perhaps a story point is many things: "...a story point estimate is
> an amalgamation of effort involved in developing the feature, the
> complexity of developing it, the risk inherent in it, and so on."[13]
Story points do not, as far as I have seen, describe risk. They do
describe effort and complexity (and they assume that effort and
complexity are just ways of saying how long it'll take to do
something.)
>
> How are story points used? Again, opinions differ wildly.
>
> Maybe the number of story points in a sprint (velocity) is a measure
> of productivity: "Truth be told velocity really is a productivity
> measure..."[8]
Yes, it is a rough measure of what got done. Some would call that
productivity. However ...
>
> Maybe story points should not be used to measure productivity: "Using
> story points or ideal days to measure productivity is a bad idea
> because it will lead the team to gradually inflate the meaning of a
> point..."[4]
Yes. It is well known that any simple measure of "productivity" can
be gamed in a large number of ways, and most of the experts
recommend against using points to measure productivity for that
reason. They /do/ measure productivity. Productivity measurement,
for most experts, is not something that should be measured (at least
from outside).
>
> Maybe story points should be burned down during a sprint: "Basic
> Truths about HyperProductive Scrum...Burn down Story points only"[6]
>
> Or maybe it�s the other way around and story points should not be
> burned down during a sprint: "I also recommend estimating the sprint
> backlog in hours rather than in points."[3]
There are many ways to track how a Sprint is going. One is to track
[burn down] points. Another is to track hours. Another, and in my
opinion the best, is to track features actually done, and to use a
kanban-style board to track status of work in process.
Understanding and practice in Agile software development change and
evolve. One reason is that the bloody POINT of Agile is to inspect
and adapt, and another is that as people try new things, the rest of
us learn about them and begin to consider and try them as well.
Overall, the center of gravity of practice changes as we learn.
>
> When it comes to story points, it�s a wild rumpus of opinion. Some
> writers believe that teams achieve steady state velocity[9], others do
> not[10].
Some teams do achieve steady state velocity. This could be done a
number of ways, only some of which would be good. A good way would
be to have a consistent assessment of difficulty in points, and
never to slow down. A bad way would be to slow down, but adjust
one's definition of points to make the same kind of thing seem
harder and harder so that points were inflated.
A team that used a consistent assessment might:
slow down if their design deteriorated;
stay the same if they kept design and capability constant;
speed up if they became more effective.
Other reasons exist for a velocity change, including staffing size
or time available. When a team's velocity changes, therefore, it is
interesting, but the magnitude and direction of the change does not
tell us anything other than to look further.
> Some believe that there is a mapping between story points
> and time[11], while others do not[12]
Unless people are using some new kind of story point that I've never
heard of, there clearly IS a mapping between story points and time.
However, there is NOT:
-- a predictable mapping;
-- a guaranteed linear relationship over time;
-- comparability between teams;
-- utility to using points as a goad.
I see nothing very contradictory here, just variances in usage and
focus. It's like a menu, really. The hamburger doesn't contradict
the fish, and you can have potatoes with either if you want to.
Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
Think! -- Aretha Franklin
Jens Meydam
>On Mar 2, 12:22 pm, Ron Jeffries <ronjeffr...@acm.org> wrote:
> Story points do not, as far as I have seen, describe risk. They do
> describe effort and complexity (and they assume that effort and
> complexity are just ways of saying how long it'll take to do
> something.)
>
I vaguely remember that David Anderson describes a measure /similar/
to story points that combines estimated effort and risk. More
estimated effort -> more points; higher estimated risk -> also more
points. More estimated effort AND higher estimated risk -> a lot more
points. I haven't found the passage in his book though.
> Some teams do achieve steady state velocity. This could be done a
> number of ways, only some of which would be good. A good way would
> be to have a consistent assessment of difficulty in points, and
> never to slow down. A bad way would be to slow down, but adjust
> one's definition of points to make the same kind of thing seem
> harder and harder so that points were inflated.
Another way would be to improve skill and understanding of the subject
matter, but to keep estimating in ideal person days, just calling the
measure "story points" to avoid constant comparisons between estimated
and clock time. As long as the team stays focused at the same level
and estimates with reasonable accuracy (or with consistent bias),
constant "velocity" will just show that the team keeps getting two
weeks' worth of work done in two weeks. (The same point Dan has
made.)
Is this good or bad? It has the benefit of simplicity. It does
undermine any attempt at objectively demonstrating acceleration
towards a "hyperproductive state" - but if I have been in touch with a
team and I have a certain level of understanding of what a well
executing team looks like I should be able to reach an informed
opinion on progress anyway.
There are other ways to use quantitative date than calculating
velocity per sprint. If there are different degrees of "Done" (for
example, done as far as the developers are concerned, installed in the
production environment but not yet used without careful monitoring,
used by all users without any monitoring) it is possible to create a
cumulative flow diagram (including data on work in progress).
Measured velocity would be the derivative of one of the "Done"
curves. Even if the data is not reliable enough for supporting an
objective judgment on changes in "real" velocity, the shape of the
diagram alone can tell a lot about how development is going.
Cheers
Jens
Ron Jeffries
> I vaguely remember that David Anderson describes a measure /similar/
> to story points that combines estimated effort and risk. More
> estimated effort -> more points; higher estimated risk -> also more
> points. More estimated effort AND higher estimated risk -> a lot more
> points. I haven't found the passage in his book though.
I don't see why risk would change the points. What does he imagine
the points are used for?
Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
If you want to garden, you have to bend down and touch the soil.
Gardening is a practice, not an idea.
-- Thich Nhat Hanh
Jens Meydam
On Mar 2, 9:34 pm, Ron Jeffries <ronjeffr...@acm.org> wrote:
> Hello, Jens. On Tuesday, March 2, 2010, at 3:08:14 PM, you wrote:
>
> > I vaguely remember that David Anderson describes a measure /similar/
> > to story points that combines estimated effort and risk. More
> > estimated effort -> more points; higher estimated risk -> also more
> > points. More estimated effort AND higher estimated risk -> a lot more
> > points. I haven't found the passage in his book though.
>
> I don't see why risk would change the points. What does he imagine
> the points are used for?
I can't speak for David Anderson, but I would say the added points
have the role of a safety margin. Let's suppose the initial, naive
estimate is 3 days but I am not sure I can really do it in 3 days
because of some special "risk". It would be unwise to commit to the
story based on the initial estimate and my velocity. Bad things that
can happen frequently do happen.
Isn't that the reasoning behind the practice of using the initial
numbers of the Fibonacci sequence for estimates? The bigger the
estimate, the bigger the risk that it is wrong. "I think it this
story will take me 4 days but that is not one of the allowed numbers,
so I must choose 5 as the estimate." If it will probably take me more
than a day or two all bets are off, anyway! :-)
Jens
Mark Levison
|
Mark
Levison | Agile Pain Relief
Consulting | Agile Editor @
InfoQ
Recent Entries: Self
Inflicted Agile Injuries, Why
use an Agile Coach |
Dan Rawsthorne
are the same. I don't compare, that is bad juju...
Dan Rawsthorne, PhD, CST
Senior Coach, Danube Technologies
d...@danube.com, 425-269-8628
Mark Levison wrote:
> Dan - ahhh, you compare velocity across teams. Please tell me it isn't
> so. So sad :-( I wrote about this evil just last week: Misuse of
> Velocity in Agile Projects
> <http://agilepainrelief.com/notesfromatooluser/2010/02/misuse-of-velocity-in-agile-projects.html>.
>
>
> Please tell me your tongue was planted firmly in cheek.
>
> Cheers
> Mark Levison
>
>
> *Mark Levison* | Agile Pain Relief Consulting
> <http://agilepainrelief.com/> | Agile Editor @ InfoQ
> <http://www.infoq.com/about.jsp>
> Blog <http://www.notesfromatooluser.com/> | Twitter
> <http://twitter.com/mlevison> | Office: (613) 862-2538
> Recent Entries: Self Inflicted Agile Injuries
> <http://www.notesfromatooluser.com/2009/12/self-inflicted-agile-injuries.html>,
> Why use an Agile Coach
> <http://www.notesfromatooluser.com/2009/11/why-use-an-agile-coach.html>
Mark Levison
No, I said you could add velocity across teams if the baseline stories are the same. I don't compare, that is bad juju...
Phew - its just my misinterpretation.
Cheers
Mark
Ron Jeffries
wrote:
>> I don't see why risk would change the points. What does he imagine
>> the points are used for?
> I can't speak for David Anderson, but I would say the added points
> have the role of a safety margin. Let's suppose the initial, naive
> estimate is 3 days but I am not sure I can really do it in 3 days
> because of some special "risk". It would be unwise to commit to the
> story based on the initial estimate and my velocity. Bad things that
> can happen frequently do happen.
That really points up the well-known fact that is rarely
acknowledged in action: an estimate should be a range.
> Isn't that the reasoning behind the practice of using the initial
> numbers of the Fibonacci sequence for estimates? The bigger the
> estimate, the bigger the risk that it is wrong. "I think it this
> story will take me 4 days but that is not one of the allowed numbers,
> so I must choose 5 as the estimate." If it will probably take me more
> than a day or two all bets are off, anyway! :-)
Yes ... I don't see that the Fib really does much for us but some
people like it.
Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
Perhaps this Silver Bullet will tell you who I am ...
Jens Meydam
> That really points up the well-known fact that is rarely
> acknowledged in action: an estimate should be a range.
I once took a class by Mike Cohn. "Estimate in ranges" was one of his
mantras, along with "Estimate size; derive duration."
Concerning buffering:
In the chapter on "Buffering Plans for Uncertainty" in his estimation
book he recommends adding a buffer at the project level, based on the
"uncertainty around the specific user stories in the project." Adding
a buffer at the story level may lead to developers starting too late
or using up the maximum possible time, even if they could have
finished earlier.
He also adds the nice caveat: "On many projects, a precise deadline
with a precise set of delivered functionality is not needed. Instead,
the team simply needs to deliver high-quality software as fast as
possible over a sustained period. If you're in this situation, don't
take on the extra work of adding buffers to your project."
> Yes ... I don't see that the Fib really does much for us but some
> people like it.
They certainly don't help much if we only use 1, 2 and 3. :-)
Another point Mike Cohn emphasized in his class was the importance to
keep estimates within one order of magnitude.
These days some people (also you?) just count small features, but it
is hard to bring everything down to a uniform size, and I find it
demotivating to "earn" no more for "big" stories than for "small"
ones. Most stories are 1, some 2 or 3, very few 5 or 8.
Funnily, I only use these small feature-level estimates for
statistical purposes - to track where the effort went and to visualize
how work flows from development into production. When I have to say
how much we will get done in the next month or year, I estimate (or
rather guess) at a much higher level - again operating with numbers
within one order of magnitude: "Sub-project A took us two months and
sub-project B seems a little easier, so B will probably also take no
longer than two months."
I use small user stories much like tasks are used in standard Scrum.
Commitment is made at a higher level.
Jens
alanatlas
Regarding the good ol' Fib, I have come to believe that it works well
because it relates to the concept from cognitive psychology of a "just
noticeable difference". The basic idea of the 'jnd' is that the the
bigger or louder or brighter something is, the larger must be the
change in it before a human can detect the change. That is why it is
difficult to see one candle burning in a window down the street in the
daytime, but easy to do at night.
So, the concept for me is that the "larger" two stories are, the
greater must the difference between them in order for me to be able to
detect it. That's why I can't tell the difference between an '8' and a
'9', but I can tell the difference between an '8' and a '13'.
And, it turns out, Mr. Fibonacci's series seems to work for jnd's as
it does so often for natural phenomena.
Break, break.
I am totally in favor of minimizing estimation or sizing activities
and therefore enjoy it when you say similar things, but I am at a loss
on one related point, which I would like to ask you about. The
question would be, "In the absence of a Product Backlog with equally-
sized stories, how can I support planning into the future?" In other
words, for all of its imperfections, an estimated backlog coupled with
a predictable velocity can enable me to have some idea of when I will
complete various stories in the future. This is the Scrum equivalent
of release planning. How can I do that if I don't do story points at
all?
Thanks.
alan
Bachan Anand
all know that story points or for that matter any estimation adds over
head and takes time . From my experience so far it is not an easy sell
if we cannot predict on when or at what rate we can deliver features .
How do we address the need for the following if we do not do story
point or person day estimation.
1) Velocity of a team and release planning .
2) Sharing of ideas within a team during sprint planning when we play
planning poker .
Ron and other , your thoughts ?
-Bachan
Ron Jeffries
wrote:
> I have the same question as Allan,how do we do release planning . We
> all know that story points or for that matter any estimation adds over
> head and takes time . From my experience so far it is not an easy sell
> if we cannot predict on when or at what rate we can deliver features .
If we're delivering features, we can observe how fast we deliver
them and that's the rate we can deliver them at.
If we're not delivering features, we can guess. It's just fine to do
that however you do it now, or any other way. They're all about
equally bad.
The main thing is that after we start, we steer the project to
success by managing scope in the light of observed velocity.
> How do we address the need for the following if we do not do story
> point or person day estimation.
> 1) Velocity of a team and release planning .
See above.
> 2) Sharing of ideas within a team during sprint planning when we play
> planning poker .
Do Quick Design Sessions instead?
Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
Hold on to your dream. --ELO
Bachan Anand
Looks like you do acknowledge that there is need to do Release
planning .What would you suggest as the measure of features , if we
use the rate at which features were delivered as a way of predicting
how features would be delivered in the future . I don't see it any
different from using story point estimation.
I would also like to better understand what you meant by " they are
all equally bad " .
I agree with your objective that we should all be focusing on steering
the project to success .
-Bachan
> --
> You received this message because you are subscribed to the Google Groups
> "Scrum Alliance - transforming the world of work." group.
> To post to this group, send email to scruma...@googlegroups.com.
> To unsubscribe from this group, send email to
> scrumallianc...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/scrumalliance?hl=en.
>
>
--
--Bachan Anand
+714 292 9642
Conscire - knowledge shared with others
Ron Jeffries
wrote:
> Looks like you do acknowledge that there is need to do Release
> planning .
I acknowledge that people do release planning. I can understand why
they would want to. I don't agree that there is "need".
> What would you suggest as the measure of features , if we
> use the rate at which features were delivered as a way of predicting
> how features would be delivered in the future . I don't see it any
> different from using story point estimation.
Then use story point estimation ...
> I would also like to better understand what you meant by " they are
> all equally bad " .
... because all forms of estimation in the absence of knowledge are
pretty much all equal: equally bad.
Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
If you're not throwing some gravel once in a while,
you're not using the whole road.
Allen Ashe
and do-we-need-to do planning for the project. We all know that no
manager is going to approve and fund a project if you can't give him/
her a date when you expect it to be done and what kind of resources
you will need. Yesterday I was watching a video of Scott Ambler's
presentation at Agile 2009 on what practices people really do. The
data was compiled from several years of surveys. It covers a number
of topics but he talks about what kind of planning people really do.
(The screen is split vertically with the video on top and the slides
displayed below.)
http://www.infoq.com/presentations/ambler-agile-by-the-numbers
Jens Meydam
On Mar 7, 6:00 pm, Allen Ashe <allena...@gmail.com> wrote:
> A lot of this discussion seems to revolve around the issue of how-to
> and do-we-need-to do planning for the project. We all know that no
> manager is going to approve and fund a project if you can't give him/
> her a date when you expect it to be done and what kind of resources
> you will need.
Dan North has written a great article on this. I quote part of it
below.
> Yesterday I was watching a video of Scott Ambler's
> presentation at Agile 2009 on what practices people really do. The
> data was compiled from several years of surveys. It covers a number
> of topics but he talks about what kind of planning people really do.
I'm not impressed by Scott Ambler's approach. I don't care what most
people do. Agile software development is often only done half-
heartedly and badly. ("How do you mean you are doing XP? You don't
have any unit tests and you are not doing pair programming!" "Yes, but
we've thrown out planning and documentation!")
Scott Ambler is employed by IBM, but when IBM introduced agile
software development internally they turned to other people, as far as
I know. The Poppendiecks have a detailed account on "Agile@IBM" in
their latest book.
Jens
http://dannorth.net/2009/07/the-perils-of-estimation
The perils of estimation
Business people want estimates. They want to know how much it’s going
to cost them to get a solution, and they want to know how likely it is
to come in on time and on budget. And of course quality is not
negotiable.
Agile teams I encounter are at best nervous about estimates and at
worst simply evasive. “You don’t need estimates if you’re doing
Agile,” they say. “It will be ready when it’s done. We’re constantly
adding value so we don’t need to commit to a date.”
[...]
My favourite exchange goes something like:
“We’ve done an inception and broken down the entire project into
stories and measured it, and it’s come in at 400 stories, estimated at
865 story points.”
“865 what?”
“865 story points.”
“So how big is a story point?”
“We don’t know yet, we’ll let you know in a few weeks.”
[...]
By introducing a comprehensive story list – with or without the notion
of story points – we have unwittingly reframed the project. The
business started out by defining success as solving the problem, but
now we have redefined success as delivering this list of stories.
However we frame it, that’s what the business will believe. The
project will start and and the business stakeholders will start
counting down the list of stories until you get to zero.
So now we have the worst of both the Agile and plan-driven worlds: the
business expects delivery of a fine-grained list of requirements
(whether we call it a Product Backlog or a Master Story List), and we
have only taken a half-hearted attempt at it compared to the big up-
front analysis we used to do. From here on we are on the back foot,
constantly negotiating with the business to manage scope, when it’s
our own fault they even care about the story-level detail. They see
the story backlog and mentally turn it 90 degrees and think of it as a
Gantt chart. Happy days!
Ron Jeffries
wrote:
> Regarding the good ol' Fib, I have come to believe that it works well
> because it relates to the concept from cognitive psychology of a "just
> noticeable difference". ...
> And, it turns out, Mr. Fibonacci's series seems to work for jnd's as
> it does so often for natural phenomena.
"Seems to work", yes. But it should work in days or hours or points
or gummi bears just as well, should it not?
> Break, break.
> I am totally in favor of minimizing estimation or sizing activities
> and therefore enjoy it when you say similar things, but I am at a loss
> on one related point, which I would like to ask you about. The
> question would be, "In the absence of a Product Backlog with equally-
> sized stories, how can I support planning into the future?"
Equally sized stories are good. And don't require points or
Fibonacci.
Arlo Belshee gave a talk at last year's Agile showing that paying
attention to cost is (sometiems) sub-optimal in the presence of high
value which cannot be accurately estimated. That is, if you choose
stories based on cost per value, this is not always ideal if value
varies enough.
A more interesting question might be to explore just what kind of
"planning into the future" we really need, and the extent to which
things like story points play into that. Especially since when we
have data we hardly need them, and when we haven't data they are
hardly useful.
> In other words, for all of its imperfections, an estimated backlog
> coupled with a predictable velocity can enable me to have some
> idea of when I will complete various stories in the future. This
> is the Scrum equivalent of release planning. How can I do that if
> I don't do story points at all?
Suppose we couldn't do that at all. What would go wrong?
Suppose we couldn't do it more than a month or so out? What would go
wrong?
Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
Resistance may or may not be futile. It is for sure not productive.
Mark Levison
I struggle with Scott's numbers - as I find his survey's are generally not at all well designed. Neither Scott, I or most others on this list have a good idea how to design and conduct a survey. As a result I don't trust the results or their interpretation.
I also agree with Jens - the behavior of the masses has little to do with good "agile".
Cheers
Mark
|
|
|
Mark
Levison | Agile Pain Relief
Consulting | Agile Editor @
InfoQ
|
|
Recent Entries: Self
Inflicted Agile Injuries, Why
use an Agile Coach
|
John Clifford
release planning. We do need to have user stories that are broken down
well enough to give us some confidence in the accuracy of our
estimates.
If we have used Fibonacci series-based measurements as our value for
story points, then a good rule of thumb is to realize that the actual
effort may range from between half our total points to twice our total
points. Obviously, the less decomposed epics (large stories) are, the
wider this range may be. There is a substantial difference between 300
points of variability and 30 points of variability. So, the goal
should be to drive down uncertainty in our estimates to the point
where we can have a reasonably accurate release plan. If we're talking
quarterly releases, then I want to be able to break down the next
three months' worth of work to sprint-sized user stories.
This is where we have to balance agility with predictability, and
realize that sometimes the effort to achieve predictability leads to
waste. If we break down a quarter's worth of user stories only to
change course after the first month, the extra decomposition work is
waste. Again, this is where 'just-enough' comes into play; we don't
want to exert a lot of effort into something that we may throw away...
and that we only need to get to the point that we know it will or
won't fit into a sprint.
One problem that seems to be almost universal is reconciling Scrum to
long-range planning, because Scrum and long-range planning seem
oxymoronic. Maybe this is because corporate management persists in
believing that it can predict the future several years out... if it
only puts enough time and effort into planning... and if the plans
turn out to be wrong then of course it's a people problem. Maybe the
800-pound gorilla knocking on the door is the reality that, although
we can plan for the future, we can't control it, and therefore too
much time and effort spent on meticulous long-range planning is waste.
Instead, we should plan in detail only for the immediate future, and
as the timeline extends our planning must inevitably become more
imprecise. More important, we should be willing to scrap our existing
plan if conditions warrant. "In the course of a lifetime, a wise man
is prepared to abandon his baggage several times."
- John Clifford
Construx Software, Inc.
http://www.construx.com
joseph....@gmail.com
As always, yours is an interesting post (below).
I am sure you have thought a lot about this subject, so I have no
particular hopes of convincing you...but for your amusement and
possibly for the edification of others (pro or con):
1. I strongly favor story points.
2. Business Value is a cost-benefit trade-off. Or delivering it is.
Not solely, but importantly. Most of the costs are in the team (are
the team).
3. All knowledge is at best approximate. I am sure that, while
E=MC(2) is surely incomplete, as were Newton's theories, you are not
suggesting that such incompleteness voids those ideas of any practical
usefulness. (Although whether the atom bomb itself was useful may be
debated, of course.)
4. Knowledge of the future is always more approximate. Nonetheless it
is mainly decisions about the future that we must take. I assume you
would have us use the best info available to make such decisions. Even
if not as good as we would wish. And, for some business people, some
sort of plan and cost estimate is among that info. (Yes, time too is
an important element in business decision making. Of course. ...I am
not being sarcastic to you, Ron. More to myself, who forgets these
things.)
4b. I don't think story points are equally bad. Any estimate of the
future is "bad", but story points are less bad. Which is good.
Meaning: A good team can typically do a more accurate estimate with
story points than with ideal days/hours. (Yes, for you lovers of
precision, some weasel words there. The future is not precise.)
5. One way that story points are a WHOLE lot better: They take much
less time to do (once a team becomes somewhat proficient) than ideal
days or hours, for example.
From the other side of the coin:
1. I completely agree that any estimate or plan for the future will
always be at least somewhat incorrect. This is no one's fault. This
is why we must enable an ability to re-decide when better information
arrives.
1b. Any foolish person who wants to "write a date in stone" has only
proved themselves foolish. And we agree there are many fools in the
world. (I am one too, occasionally, so I have compassion. My friends,
to amuse themselves, will debate how often.)
2. It is altogether too true that, among other things, we don't
understand what the customer wants, and we (I think always) can
discover better the "minimum marketable feature set" as we build it
and get feedback.
So, we can agree again, in general, that early plans or estimates
follow the law of diminishing returns for added effort. What remains
to be found is exactly where we cut that work off. In a specific
situation.
Related to this is the human desire for safety and perfection. We
desire to know the future "perfectly" well. So, my aphorism is: "If
you wait for perfection, you might wait too long."
Well, I hope you smiled at least once. And the smiles outweighed the
winces.
Regards,
Joe
LeanAgileTraining.com
PS for others: I have not included all the arguments that favor story
points, especially vis-a-vis ideal days or hours.
Tobias
enough to calculate velocity (if necessary) and make a release plan
(if necessary).
As for ROI...
Developer: this story will take quite a lot of work.
PO: and it doesn't provide much value
Both: let's not do that one.
And so on. It's a sort of dialog-over-data thing.
Tobias
On Mar 8, 11:57 am, "jhlit...@kittyhawkconsulting.com"