Story point estimating

[Patti]

Hi everyone,
I am scrum master for a team that is new to scrum. We are at the
beginning of a project, (Starting sprint 4) in the design phase, so
getting started has been a little rocky but the team has embraced it
and was doing fine until just recently; there have been grumblings
about changing our estimating from story points to hours. For
project tracking we had started out with a WBS estimated in hours
(months before we decided to do scrum) and we are using Greenhopper
and Jira which asks for your tasks to be estimated in hours. I have
a management that is more comfortable with hours and that is asking
for an hour estimate for the entire project. We have a list of
stories but have not estimated all of them (some 100-150 stories)

Is anyone using Greenhopper and if so do you use story points and
hours? What happens when you have one story with say 20 story points
and the developer broke it into tasks with say 30 hours and there is
another story with 15 points and that story is broken into tasks that
total 45 hours (less complex but tedious work). Some are feeling the
estimating is not consistent.

Does anyone use a relation of story points to hours?

Any help would be greatly approciated.

[Vernon Stinebaker]

There is no concept of 'phases' such as 'design phase' in Scrum. All analysis, design, development, testing, etc. relative to the potentially shippable product increment being delivered are performed within the sprint.

The problems you're describing indicate some significant gaps in your application of Scrum that would likely be better addressed by having a qualified coach come in and work with the team to cement an effective understanding of Scrum principles and practices within the team/organization.

Mike Cohn's excellent book on User Stories provides additional information on agile estimation, and more information is available on his website mountaingoatsoftware.com.

While others might want to take a stab at this, I don't think this is a topic that lends itself to resolution over email, so I'll leave my comments to the recommendations above.

Thanks,
Vernon

> --
> 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.
>

[Kurt Häusler]

I don't use Greenhopper, but normally tasks are estimated in hours rather than story points.

However when estimating the "entire project" you will probably get the best approach by estimating the entire backlog of PBIs in story points, dividing that by the velocity in story points per sprint, and then you have the best current estimate for how many sprints the entire backlog will take. This estimate should improve over time as the velocity stabilizes, and the team gets better at estimating.

It is quite normal to perceive an inconsistency between estimates of a story in story points, and estimates of tasks in hours. This is because the story points are telling you something about the magnitude of the problem that needs to be solved. (I hope this is obvious, as the PBI is usually estimated in backlog grooming, when only the PBI and acceptance criteria are known, whereas the team only begins to think about the solution during planning, when the PBI is broken up into tasks or SBIs) The task estimates in hours, are telling you something about an actual solution to the problem. It is possible that the team has certain strengths in some areas, and weaknesses in others. Perhaps a large problem of 20 points could be solved with a clever solution that takes 4 hours, whereas a small problem of 5 points could take 10 hours to solve because the team is unfamiliar with some technology for example.

But I wouldn't get too hung up about it, the hour estimates of tasks are only used for the sprint burndown chart, and many teams don't even bother estimating them and simply count the number of tasks remaining for the burndown.

One thing I noticed was that you were talking about a design phase. This could be a serious problem, if it means what I think it does. I am sorry to say, but you can only really calculate a good value for velocity when you are delivering complete software each sprint, which is the normal way of using Scrum to develop software. Normally we take a PBI or user story, and do all the tasks like analysis, design, development and test on that story within the sprint, so we are finished with actual running software. I am concerned that with your use of the term "design phase" you might only be taking analysis documents and turning them into design documents or something. This will give you a strange value of velocity that won't help you predict the delivery of actual software at all, and Scrum is not usually used this way anyway.

Hopefully I misunderstood what you meant by "design phase".

And to answer the final question, the relation of story points to hours is velocity. I don't know if this is useful, but I see the time required to complete a PBI as having two components. That which can be estimated before hand, at least as a relational unit in comparison to other PBIs, and a component that is only measurable afterwards, and depends a lot on the solution that is yet to be chosen, and the capacity of the team. The story points value relates to the first component, and velocity encapsulates the other component.

Basically it doesn't make sense to estimate PBIs in hours, because you just don't know what the solution will look like. However velocity tells us how long it took us to solve problems of certain sizes in the past, so we can use that to make an estimate in hours if we really need to.

[Manoj Vadakkan]

Hello Patti, 

This question make me think that your team has done 3 sprints of Analysis and now with the 4th sprints, you are starting to do design? Did I get that right? 

If that is the case, story points vs hour estimate may not be the biggest problem here. The understanding of Scrum itself is a problem. if you are using the Scrum frame work, you don't have Analysis phase sprints and design phase sprints. Instead, every sprint starting from the first sprint deliver potentially shippable product increment. 

As for the estimation, what are you estimating in story points? Are that tasks/activities that you had in the WBS ? 

15 point story and 20 point story breaking down to 45 and 30 hours: from your question, it sounds the 20 pointer is a large because it is more complex. As Mike Cohn once said in his article, it is not how hard you have to think it is how long it takes to do the work that contributes to the size. 

When you say the team had some grumblings and now they have accepted it, what do you mean? how are they accepting it? 

 

As for management asking for hour estimates for the whole project: yes, you will want to do that level of estimate as well. However, it is not done by estimating everything you need to do in number of hours upfront. Why not? because it will take too much time upfront to do that in the first place. even then, the presumed accuracy you would get from that type of estimation is not real. Moreover, things change during the course of the project. So how do we do it? Estimate your stories in story points and figure out how many stories you can do in one sprint. Now you can figure out approximately how many sprints you will need to complete the project.  "Agile estimation and planning" by Mike Cohn will be a good resource for you. It sounds like you will need some help from people who have done his type of work before. You may look up Scrum Allilance website for people near you and Scrum user groups near your area. If I know where you are, I may be able to refer you to groups and people near you. 

Manoj

http://manoj.vadakkan.org/ 

  

  

[Gustavo Cebrian Garcia]

Hello,

You want to get a potencially shippable product, fine. However, if you need a finished product by a certain date, you will
need to spend more time in analysis in some spritns. What doy ou think about this?

Gustavo.

[Ron Jeffries]

Hello, Gustavo. On Saturday, June 4, 2011, at 4:35:04 PM, you
wrote:

> You want to get a potencially shippable product, fine. However, if you need
> a finished product by a certain date, you will
> need to spend more time in analysis in some spritns. What doy ou think about
> this?

To do software development with Scrum well, you must deliver
software, in a potentially shippable form, in every Sprint, from the
first to the last. Naturally, the software toward the end will have
more features and will be a better product in many ways.

Assuming a flat number of people on the team, their ability to
produce features should be approximately flat from the beginning to
the end. Therefore the amount of design that is needed is also
roughly flat from the beginning to the end. That said, early Sprints
will be more exploratory in both analysis (feature selection) and
design, and later ones more focused on quality and the like.

This is not an authorization to have analysis Sprints at the
beginning and Testing Sprints at the end.

Ron Jeffries
www.XProgramming.com
Don't confuse more exact with better. -- Brian Marick

[Andreas]

A very good approach to understand the heartbeat of Scrum is the
lecture of Nonaka's and Takeuchi's "New New Product Development Game":

http://hbr.org/product/new-new-product-development-game/an/86116-PDF-ENG

This is one of the core sources Jeff Sutherland used to construct
Scrum. You will find a very enlightening treatment of the concept of
overlapping phases. Scrum uses the combination of analysis, design,
implementation, testing and implementation to an extreme. This does
not mean that you should skip to think about the critical functional
and non-functional requirements of a system in the beginning. However,
if you do not start to create a potentially shippable product
increment from the first sprint, you will most likely run into serious
problems afterwards. I fully copy Ron's musings about this matter.

So forget about phases, think about activities. These activities might
require a different amount of effort and intensity over the course of
your product development. But they are all there from the first day.

This is a challenging mission. Nobody claims that it is easy to adapt
Scrum.

Back to the story points: Story point estimation is based on the
relative evaluation of completed functionality. It is possible to
apply this to tasks, yet it will degenerate into just another factored
unit of time based estimation. The benefits of relative complexity and
size based estimation, better predictability, better transparency
about the effects of decisions, better understanding of a team's
capacity and velocity improvement, will not occur if you are misusing
this practice.

Do not be afraid to have a poor Scrum implementation to start with.
Scrum is about identifying your shortcomings and encouraging you to
address them.

Andreas

[Sameh Zeid]

Hi Patti,

My 2 cents here is to become less concerned with the Agile tool, and to become more focused on the requirement of Scrum framework. This framework is usually explained in details in the CSM 2-days course. Then, as you figure the gaps between where you are now and Scrum requirements, start evaluating and implementing actions which would evolve your system.

Regards,

Sameh

On Fri, Jun 3, 2011 at 9:36 AM, Patti <pamc...@sbcglobal.net> wrote:

--
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.

--
Sameh Zeid
Email: sameh...@gmail.com, Phone: (226)444-1794, Cell Phone: (716)748-9691
Twitter: @sameh_zeid, Skype: samehsz
profile: http://www.linkedin.com/in/samehzeid
blog: methods4software.wordpress.com

[George Dinwiddie]

Hi, Patti,

As others have said, this doesn't sound kosher. To be honest, I no
longer recommend breaking stories down into tasks, but into thinner
stories that can be proven by an example. See
http://blog.gdinwiddie.com/2011/05/01/splitting-user-stories/ for a
really simple way to do that (as well as some links to other ways). And
I suggest delivering working software from the git-go, even though it
might not be much. See
http://blog.gdinwiddie.com/2011/05/25/avoiding-iteration-zero/ for more
on that.

I'd be happy to answer any questions you have on those articles and how
to apply that to your situation. I'm headed out to the Agile
Development Practices Conference in the morning, though, and probably
won't keep up with the mailing list while I'm there. Ping me at
gdinwiddie at idiacomputing.com if I miss an important question here.

- George

P.S. The abbreviation of estimate is "guess." Don't worry about the
inconsistency. Do track your velocity over time and see if it settles
into a groove.

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------

[joseph....@gmail.com]

Hi Patti,

As someone already said, we don't want to think of the usual WF
'phases' anymore.

We do Release Planning, usually for a couple of days (depends on
several factors, but mainly release size). Then we start Sprinting.
In the first few Sprints, we might have some Infrastructure,
Architecture, and Design stories, but we also do User Stories (regular
software dev stories....well, I assume you are building a SW
product). Every story might also have a design task or at least some
design work.

Strongly recommend staying with Story Points. I talk often about
"Velocity: Don't leave home without it!"

See Mike Cohn's Agile Estimating and Planning book.

The basic idea is that Velocity (story points of done, done work in a
sprint) ties 'work' to team time (eg, 2 weeks of team time, given a 2
week sprint). This is useful info for everyone, including managers.

Velocity is also more flexible and actually more understandable. And
it measures an output (a done, done story), not an input (a person
hour).

The illusion is that everyone understands a person hour the same way.
But this is total illusion.

Again, also, inputs are irrelevant...only outputs are meaningful.

I guess it bears saying that the stories completed must be valuable.
Else you are measuring an output of, well, no value.

I see many 'scrum tools' and have seen greenhopper recently. But
frankly don't remember it perfectly well. My recollection is that it
was customizable, so that you could collect story points quite
readily.

Consistency.... Well, OF COURSE, estimates of small amounts of work
are not consistent. Estimating is very hard. But we do want the
'actuals' to show a normal distribution around the estimated number.
What is really interesting is that the variance for the TOTAL story
points for a sprint is much tighter (if there are many stories) than
for a single story. This is basic statistics, but essentially is the
idea that some under-estimates offset some over-estimates, so the
overall estimate (of total story points for the sprint) is more
accurate.

Now, estimating is hard and some teams start off being very bad at
it. They might study some of the worst estimated stories and learn
how to estimate better going forward. But expecting ANY team to be
consistently accurate at the story level is silly and unnecessary.
Where they ever that accurate before with hour estimates? (I am sure
the answer was 'no'.)

We do NOT tell the team about any relationship between story points
and hours. They just make a relative size-complexity comparison.
People are terrible at estimating time (the studies show) but quite
good at estimating relative size-complexity.

Again, for managers, what they need to know is how much real progress
per Sprint (amount of working software per sprint). Story points with
a good definition of done drives a bunch of good conversations that
can make this productivity better and more professional (eg, less and
less technical debt being built). They also want to compare the value
produced in a sprint versus the cost of the sprint. Well, this is
another conversation....

With a good coach, story pointing is something that most teams can
pick up quickly. With no coach, they often just go back to estimating
time, which is really bad and feels 'bad' in several ways.

Hope this helps.

Thanks,
Joe

[Gustavo Cebrian Garcia]

I agree Ron, this is compatible with saying that if you need to present a set of importante feature for a certain date,
you will ahve sprints in which you spend more time in Analysis ( as you say) Of course you still need to present
a potencially shippable product...

Adaptability Vs Preditability --> Mike Cohn

--

[Manoj Vadakkan]

Hello Gustavo, 

By doing more of analysis in the beginning are you trying to reduce the risk of not able to deliver those set of important features by that certain date? 

btw, doesn't almost all the project that we deal with have that certain date and those definite set of features handed to us anyway? 

Manoj

http://manoj.vadakkan.org/ 

[Gustavo Cebrian Garcia]

On 5 June 2011 15:42, Manoj Vadakkan <manoj...@gmail.com> wrote:

Hello Gustavo, 

By doing more of analysis in the beginning are you trying to reduce the risk of not able to deliver those set of important features by that certain date? 

Exactly.
 

btw, doesn't almost all the project that we deal with have that certain date and those definite set of features handed to us anyway? 

What do you mean?
If we can not deliver for sure, we just do not start or stop the analysis.

Gustavo.

[Ron Jeffries]

Hello, Gustavo. On Sunday, June 5, 2011, at 3:18:46 PM, you wrote:

> If we can not deliver for sure, we just do not start or stop the analysis.

How do you know whether you can deliver for sure without doing the
analysis? If you know you can deliver for sure before analysis, why
bother to do the analysis?

Ron Jeffries
www.XProgramming.com
The practices are not the knowing: they are a path to the knowing.

[Gustavo Cebrian Garcia]

On 5 June 2011 22:25, Ron Jeffries <ronje...@acm.org> wrote:

Hello, Gustavo.  On Sunday, June 5, 2011, at 3:18:46 PM, you wrote:

> If we can not deliver for sure, we just do not start or stop the analysis.

How do you know whether you can deliver for sure without doing the
analysis? 

You can not. Did I say you can?
 

If you know you can deliver for sure before analysis, why
bother to do the analysis?

Ron Jeffries
www.XProgramming.com

The practices are not the knowing: they are a path to the knowing.

--

[Ron Jeffries]

Hello, Gustavo. On Sunday, June 5, 2011, at 4:33:25 PM, you wrote:

>> > If we can not deliver for sure, we just do not start or stop the
>> analysis.
>>
>> How do you know whether you can deliver for sure without doing the
>> analysis?

> You can not. Did I say you can?

I think so. I think you said "If we can not deliver for sure, we
just do not start [or stop] the analysis." If you don't start it,
how do you know?

Ron Jeffries
www.XProgramming.com
In times of stress, I like to turn to the wisdom of my Portuguese waitress,
who said: "Ol�, meu nome � Marisol e eu serei sua gar�onete."
-- after Mark Vaughn, Autoweek.

[Gustavo Cebrian Garcia]

We start the analysis, of course, I meant that if we just see with a brief study that it is going to be difficult

or in the first stages of the analysis, we just stop the project.

( I understand the misunderstanding, sorry )

On 6 June 2011 00:57, Ron Jeffries <ronje...@acm.org> wrote:

Hello, Gustavo.  On Sunday, June 5, 2011, at 4:33:25 PM, you wrote:

>> > If we can not deliver for sure, we just do not start or stop the
>> analysis.
>>
>> How do you know whether you can deliver for sure without doing the
>> analysis?

> You can not. Did I say you can?

I think so. I think you said "If we can not deliver for sure, we
just do not start [or stop] the analysis." If you don't start it,
how do you know?

Ron Jeffries
www.XProgramming.com

In times of stress, I like to turn to the wisdom of my Portuguese waitress,

who said: "Olá, meu nome é Marisol e eu serei sua garçonete."

 -- after Mark Vaughn, Autoweek.

--

[Matheus Henrique Gorino]

I saw you saying about complex vs. tedious work when estimating Stories and what I say to my teams is that tedious work should also be taken into account when estimating in Story Points.

Story Points should indicate the relative SIZE of a Story, and in this measure of "size" I ask then to take into account:

- Complexity

- Risk (never-done-before features, new technology, etc)

- Amount of tedious work (and I'd also wanted to say that the more tedious and quantity of this kind of work, the less programmers focus on the tasks and more bugs are generated).

So a Story with low complexity but lot of tedious work might be bigger than a more complex one.

[Ron Jeffries]

Hello, Matheus. On Monday, June 6, 2011, at 10:00:03 PM, you
wrote:

> I saw you saying about complex vs. tedious work when estimating Stories and
> what I say to my teams is that tedious work should also be taken into
> account when estimating in Story Points.
> Story Points should indicate the relative SIZE of a Story, and in this
> measure of "size" I ask then to take into account:
> - Complexity
> - Risk (never-done-before features, new technology, etc)
> - Amount of tedious work (and I'd also wanted to say that the more tedious
> and quantity of this kind of work, the less programmers focus on the tasks
> and more bugs are generated).

> So a Story with low complexity but lot of tedious work might be bigger than
> a more complex one.

When we invented Story Points, we had in mind simply "how long will
it take to do this story". If one must use them, this still seems to
me to be the best definition.

Ron Jeffries
www.XProgramming.com
Master your instrument, master the music,
and then forget all that *!xy!@ and just play. -- Charlie Parker

[Vernon Stinebaker]

> When we invented Story Points, we had in mind simply "how long will
> it take to do this story". If one must use them, this still seems to
> me to be the best definition.

Then why not just use time?

>
> Ron Jeffries
> www.XProgramming.com
> Master your instrument, master the music,
> and then forget all that *!xy!@ and just play. -- Charlie Parker
>

[Ron Jeffries]

Hello, Vernon. On Monday, June 6, 2011, at 11:48:52 PM, you wrote:

>> When we invented Story Points, we had in mind simply "how long will
>> it take to do this story". If one must use them, this still seems to
>> me to be the best definition.

> Then why not just use time?

Currently Chet and I do not recommend this kind of estimation at
all, as it too often generates the kind of problems often discussed
here.

Story points were invented for political reasons:

At the time we invented story points, the team in question had been
estimating in "Ideal Time", the time it would take to do the story
if not interrupted. We had already found "Actual Time" to be too
hard to yse, both in estimating and politically, since in our
environment, "estimate" meant "promise" to many managers. Ideal Time
was supposed to be a new kind of unit that didn't have that
promissory aspect.

What we found in use, however, was that Ideal Time was itself a
problem because now you'd say you could do something in two Ideal
days, and five days later it would be done. Management couldn't seem
to make use of this.

By this time we had a hard deadline, and our "Product Owner" was
pretty good at managing scope, so we didn't have much need for
managers to be seeing how we did on estimates. They just couldn't
help it when they saw things like "days". So we invented story
points, with some definition like "one story point is one-half an
ideal day".

Time is probably a better way of estimating if the environment is
healthy enough to understand the difference between estimate and
promise. In my experience few organizations are.

Day in and day out, the main purpose of estimation is to decide how
much work to put in the Sprint. I find that rather than do some kind
of numerology on time, utilization, who's on vacation, and all the
other factors people worry about, this works better:

Make the stories all pretty small, no more than two or three days'
work for a pair. Stories this small will be easier to understand,
and the law of large numbers will be on your side.

After the Product Owner gets what looks like enough stories up on
the wall during Sprint Planning, the development team looks at
them, look each other in the eyes, and draw a line, committing as
a group to the stories above the line.

TL;DR

Story Points were invented to obfuscate duration so that certain
managers would not pressure the team over estimates. Using elapsed
time is probably better if the environment is healthy enough not to
obsess over meeting the estimates. Slicing stories small and
committing as a team to the batch provides better commitment, more
accurate selection of work, easier tracking, and less political
pressure.

Ron Jeffries
www.XProgramming.com
The main reason that testing at the end of a development cycle finds
problems is not that problems were put in near the end, it is that
testing was put off until then.

[Vernon Stinebaker]

Thanks for the additional detail Ron.

I concur with the approach you and Chet are now recommending, thought I find it works best with more mature teams. For teams with less experience I still find story points, completely devoid of discussions of time (strictly discussing and comparing relative effort against a baseline or, as more stories are added, comparing against multiple points of reference) along with velocity provide teams with a good tool for estimating and planning. After estimating I still encourage the teams to do a 'gut check' to make sure they're confident of being able to deliver to their commitment. I never encourage the use of time because, as you describe below, it confuses the issue. I see story points and relative estimation as an intermediate step in moving towards the more ideal approach of commitment based (sprint) planning.

Thanks,
Vernon

[Patti]

Hi Manoj,
Thanks for your reply,

no we have not done analysis in all these sprints though we are doing
some investigation in some cases. We are using alot of technologies
new to the team. Most of the team ramped up on these and trainied
before we started the sprints. As I described to Vernon, we are
building a product from scratch so each story requires putting
frameworks or parts of frameworks in place. In the scrum training I
took I asked the group how they handle a story that does not create a
feature, such as investigating and implementing a framework versus 'II
want to start an acqusition so I can see the data as it is
collected' They suggested having a story for for those tasks also,
so we would make the implementation part of a story and maybe make the
investigation and decision a story that delivers a decision and brief
document with examples of how to use.

I would ask the community how do you start a large project from
scratch like this with scrum, when the first few months are putting
the acrhitecture in place?

I agree with your comment about the hours taking more time. This is
where i think we went wrong. We have not estimated all our stories up
front so we do not have an idea of the total number of story points
yet. We need to do this ASAP. Management has stepped in and is
asking the team to estimate hours while I am easking them to estimate
stories. I think this is a problem and we are wasting too much time
estimating.

> Manojhttp://manoj.vadakkan.org/<http://www.linkedin.com/redirect?url=http%3A%2F%2Fmanoj%2Evadakkan%2E...>

> >http://groups.google.com/group/scrumalliance?hl=en.- Hide quoted text -
>
> - Show quoted text -

[Patti]

Hi Vernon,

Thanks for your response. I too feel we need a coach and am looking
into that. I mentioned a design phase because even though we are
doing scrum, our manaement has put in place a product development
process that includes phases so we are stuck with trying to fit the
two together. As I said we are new to this and changing a process
that has been in place for many years and many departments will not be
easy.

we are replacing a product from scratch. our product will be client
server that on the backend controls some data acqusition devices.
one of the first stories we did was 'open device and get data' we
were able to do this with some prototyping and cheating on the backend
but there is no way it would be a shippable product after the first,
second, or even third sprint. After our second sprint the team felt
they needed to put more of a foundation in place to start building
stories on. For instance frameworks for exceptions, sessions, a
device manager, plugin frameworks, data persistance, etc. So we
still have stories from a user point of view but they are more like
epics because they require so much work over all the layers of the
application that are not even in place yet. Our sprints have been
productive and we are building a product much faster than we would
have had we uses waterfall I feel.

for some reason the issue of hours versus stories was raised and one
experienced person on the team said that could be done. I don't see
that as a very efficient way to go as I would think it would take more
time than estimating complexity.

Patti

On Jun 4, 9:17 am, Vernon Stinebaker <vernon.stineba...@gmail.com>
wrote:

> There is no concept of 'phases' such as 'design phase' in Scrum. All analysis, design, development, testing, etc. relative to the potentially shippable product increment being delivered are performed within the sprint.
>
> The problems you're describing indicate some significant gaps in your application of Scrum that would likely be better addressed by having a qualified coach come in and work with the team to cement an effective understanding of Scrum principles and practices within the team/organization.
>
> Mike Cohn's excellent book on User Stories provides additional information on agile estimation, and more information is available on his website mountaingoatsoftware.com.
>
> While others might want to take a stab at this, I don't think this is a topic that lends itself to resolution over email, so I'll leave my comments to the recommendations above.
>
> Thanks,
> Vernon
>

> > For more options, visit this group athttp://groups.google.com/group/scrumalliance?hl=en.- Hide quoted text -

[Jan Beaver]

I've worked in software for 25 years, which I realize is a tiny sample
size when compared to the combined experience of Ron and Chet, but in
that time I have not encountered a single organization that could
distinguish between a time estimate, whether on the calendar or using
Ideal Days/Hours, and a commitment. As a result, I always recommend
story points to my coaching clients. Story points change -- or better
yet -- provoke the conversation on the difference between an estimate
and a commitment. That, by itself, is of enormous value.

Just my (very late in the thread) two bits...

Cheers,
Jan Beaver, PhD, CSP

[Chet Hendrickson]

Hello Jan,

Its good to see that your experience is similar to ours.  

I think another way to approach our style is to reflect on the efficacy of Fibinacci sizing.  The interval between numbers in the Fininacci sequence increases as you go up.  This reflects the increase in uncertainty about estimates as the story gets larger.  Our process handles this by not allow stories above a fairly small threshold, threeish days work.   I am sure Ron could jump in with an explanation of how the Central Limit Theorem will cause the total estimation error under our approach to be small than under the standard approach, but I know I would rather he didn't.:)

chet   

.





-- 
Best regards,
 Chet Hendrickson                          mailto:li...@hendricksonxp.com
 Check out our upcoming CSM Plus courses @
http://hendricksonxp.com/index.php?option=com_eventlist&Itemid=28

[George Dinwiddie]

Patti

On 6/4/11 10:41 AM, Patti wrote:
> Hi Manoj,
> Thanks for your reply,
>
> no we have not done analysis in all these sprints though we are doing
> some investigation in some cases. We are using alot of technologies
> new to the team. Most of the team ramped up on these and trainied
> before we started the sprints. As I described to Vernon, we are
> building a product from scratch so each story requires putting
> frameworks or parts of frameworks in place. In the scrum training I
> took I asked the group how they handle a story that does not create a
> feature, such as investigating and implementing a framework versus 'II
> want to start an acqusition so I can see the data as it is
> collected' They suggested having a story for for those tasks also,
> so we would make the implementation part of a story and maybe make the
> investigation and decision a story that delivers a decision and brief
> document with examples of how to use.

For learning about something so that you can make a decision, I suggest
treating it as a "spike." This is different from as story, in that it's
not creating deliverable functionality. Start with the question you
want to answer, to give a goal to the work. Such a question might be
"How do you use framework X to do Y?" Also, set a time limit on the
work so that it doesn't become a permanent research project. If the
time limit is reached without answering the question, make an explicit
decision whether to extend the spike or to try a different approach.

> I would ask the community how do you start a large project from
> scratch like this with scrum, when the first few months are putting
> the acrhitecture in place?

Grow the architecture as the code requires it. Let deliverable
functionality be the driver.

- George