[SCRUMDEVELOPMENT] Re-estimating PBIs

[[e-mail] [SCRUMDEVELOPMENT]]

Hi,

My current team has been asked to re-estimate PBIs: at the end of the sprint to make sure PBIs turned out to be of the size they had been estimated initially, and at the beginning of the sprint for those PBIs that has been carried over from previous sprints as not done.

Therefore, my question i: whether re-estimation of PBIs is considered to be a good practice or bad, what pros and cons are intrinsic to this approach.

[Michael Vizdos [e-mail] [SCRUMDEVELOPMENT]]

My recommendation is to get better the next time.

Use the learnings from your retrospective and get better next time.

The estimations do not matter. It's past or future.

And to your customers or end users, what matters is that you Focus and
#deliver.

More info I am sure is coming on this topic in this thread lol...

Thank you.

Mike
www.michaelvizdos.com
www.implementingscrum.com

Post by ***@gmail.com [SCRUMDEVELOPMENT]
Hi,
My current team has been asked to re-estimate PBIs: at the end of the
sprint to make sure PBIs turned out to be of the size they had been
estimated initially, and at the beginning of the sprint for those PBIs that
has been carried over from previous sprints as not done.
Therefore, my question i: whether re-estimation of PBIs is considered to
be a good practice or bad, what pros and cons are intrinsic to this
approach.

[Markus Gärtner [e-mail] [SCRUMDEVELOPMENT]]

Hi Hennadii,

I'd be interested whether you expect different answers on this mailing list than you received on the Scrum Alliance public list the past week.

We'll see.

Best Markus

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

http://www.shino.de/blog
http://www.mgaertne.de
http://www.it-agile.de

Post by ***@gmail.com [SCRUMDEVELOPMENT]
Hi,
My current team has been asked to re-estimate PBIs: at the end of the sprint to make sure PBIs turned out to be of the size they had been estimated initially, and at the beginning of the sprint for those PBIs that has been carried over from previous sprints as not done.
Therefore, my question i: whether re-estimation of PBIs is considered to be a good practice or bad, what pros and cons are intrinsic to this approach.

[[e-mail] [SCRUMDEVELOPMENT]]

Markus,

Actually I posted these questions at the same time. It just happened that this question had been approved much later.

I'm interested to hear all the opinions :) that's why I posted the question twice

[Markus Gaertner [e-mail] [SCRUMDEVELOPMENT]]

Oh, that makes sense. Thanks for clarifying. :)

Best
Markus

Scaling Agile as if you meant it: http://www.scaledprinciples.org
--
Dipl.-Inform. Markus Gaertner
Author of ATDD by Example - A Practical Guide to Acceptance Test-Driven
Development

http://www.shino.de/blog
http://www.mgaertne.de
http://www.it-agile.de

Post by ***@gmail.com [SCRUMDEVELOPMENT]
Markus,
Actually I posted these questions at the same time. It just happened that
this question had been approved much later.
I'm interested to hear all the opinions :) that's why I posted the question twice

[[e-mail] [SCRUMDEVELOPMENT]]

Hi all


As already mentioned, why hve the team been asked to do this re-estimation? Where's the value?


This question is most often asked from a lack of understanding on the askers behalf about what Sprint Commitment actually means.


The Development Team is NOT, I repeat NOT, committing to the Stories (PBI) that have been taken into the Sprint; they are committing to the Sprint Goal (see latest Scrum Guide page 9); the Sprint Goal must NEVER be to complete all Stories taken into the Sprint.


I assume your PB has an MMF or MVP (ie minimum for the project). The burn down-chart with the average velocity over the last 3 Sprints extrapolated to the end of the project will tell you whether you are likely to meet your minimums.


As soon as it looks even slightly likely that you will not meet your minimums, you must revisit the remaining PBI with a view to breaking up the larger ones, reestimating and re-ordering.


In my opinion (and hard won experience) it is a waste to visit all the estimates at the end of every Sprint.


Is the Product Owner happy with progress? If he/she is, then it is no business of IT management to interfere (you need to make this point diplomatically!!)


Hope that helps


Steve

[Cass Dalton [e-mail] [SCRUMDEVELOPMENT]]

In my view, there are two main types of estimation in agile. The first is
by-the-team, for-the-team. It is to give the team a guage for when work is

decomposed sufficiently, for them to feel confident about what they can
commit to in a sprint, and for them to look back at the end of a sprint and
reanalyze how they saw a PBI at the beginning of the sprint if the PBI took
longer than expect. This type of estimation is used for the team to grow
and improve.
The second, and more common, type is the old program management type of
estimate for planning and performance "management" (I.e. retribution for
failed commitments).
If someone is asking for reestimation, my guess is it is for the latter.
If work is taking longer than estimated, the answer shouldn't be
reestimation. It should be reexamining how the work was viewed and
decomposed.

Post by ***@gmail.com [SCRUMDEVELOPMENT]
Hi,
My current team has been asked to re-estimate PBIs: at the end of the
sprint to make sure PBIs turned out to be of the size they had been
estimated initially, and at the beginning of the sprint for those PBIs that
has been carried over from previous sprints as not done.
Therefore, my question i: whether re-estimation of PBIs is considered to
be a good practice or bad, what pros and cons are intrinsic to this
approach.

[[e-mail] [SCRUMDEVELOPMENT]]

Re-estimating PBI's is almost the worst thing that you can do. Planning is done in estimates, not actuals (obviously), and the best thing you can ask for is that the estimates remain consistent over the course of the project.

It rarely matters how good or bad the estimates are. The Team will learn how big a quantity of estimates they can do in a Sprint, and that will guide them when doing planning. Let's say that a team habitually underestimates by a factor of ten, which is pretty huge. Eventually they'll learn that they can only put about 1/10 as much work into a sprint than the man-day math would tell them they should be planning.

That's one of the reasons for using a non time based estimating system: so you're not tempted to do man-day math and futz around with the estimating. The team will learn to put x number of story points (or work bananas, or effort widgets, or whatever) into a Sprint.

The idea is to be able to right-size a sprint in order to provide medium-term predictability, and to keep the team energized with achievable goals and constant progress. As long as the estimates do this, there's really no point to try and improve the estimates.

There's one caveat though, if the estimates are bad in a way that they can't give any predictability - for instance, if they are wildly under on one sprint and then wildly over on the next - then you'll need to improve the estimating. My guess would be that most estimating that most programmers do is going to average out to be consistently under by a fairly steady factor.

dave

[George Dinwiddie [e-mail] [SCRUMDEVELOPMENT]]

Dave,

Very well said! I have one alternative to suggest. See below...

Post by ***@lawpro.ca [SCRUMDEVELOPMENT]
Re-estimating PBI's is almost the worst thing that you can do. Planning
is done in estimates, not actuals (obviously), and the best thing you
can ask for is that the estimates remain consistent over the course of
the project.
It rarely matters how good or bad the estimates are. The Team will
learn how big a quantity of estimates they can do in a Sprint, and that
will guide them when doing planning. Let's say that a team habitually
underestimates by a factor of ten, which is pretty huge. Eventually
they'll learn that they can only put about 1/10 as much work into a
sprint than the man-day math would tell them they should be planning.
so you're not tempted to do man-day math and futz around with the
estimating. The team will learn to put x number of story points (or
work bananas, or effort widgets, or whatever) into a Sprint.
The idea is to be able to right-size a sprint in order to provide
medium-term predictability, and to keep the team energized with
achievable goals and constant progress. As long as the estimates do
this, there's really no point to try and improve the estimates.
There's one caveat though, if the estimates are bad in a way that they
can't give any predictability - for instance, if they are wildly under
on one sprint and then wildly over on the next - then you'll need to
improve the estimating. My guess would be that most estimating that
most programmers do is going to average out to be consistently under by
a fairly steady factor.

My experience is that if estimates are see-sawing like that, you can do
much better by dropping estimates and just counting the stories. If that
doesn't help enough, you can spend your effort on splitting stories
rather than improving estimation. It works wonders!

- George

[Ron Jeffries [e-mail] [SCRUMDEVELOPMENT]]

Hi Dave,

I’d add this 


Post by ***@lawpro.ca [SCRUMDEVELOPMENT]
There's one caveat though, if the estimates are bad in a way that they can't give any predictability - for instance, if they are wildly under on one sprint and then wildly over on the next - then you'll need to improve the estimating. My guess would be that most estimating that most programmers do is going to average out to be consistently under by a fairly steady factor.

Even here, I’m not sure I’d look to estimation first. I suspect that if a team’s performance versus plan is erratic, there is likely something erratic happening to them. Perhaps there is a lot of tech support, or a lot of interruptions, or people are being pulled off, etc.

I’d look for the cause, in the retrospective, far before I’d suggest re-estimation.

And I’m sure you would, as well. :)

Ron Jeffries
www.XProgramming.com
Wisdom begins when we learn the difference between "that makes no sense" and "I don't understand". -- Mary Doria Russell

[[e-mail] [SCRUMDEVELOPMENT]]

Estimating work once the work is done is great. You will be 100% accurate—and more importantly you will prove that all the previous guesswork was wrong. Telling people they are wrong is a very good way to keep them in their place, and maintain control. So I say go for it. You may also want to introduce a punishment system based on just how wrong they were, say prohibiting a coffee break if a little bit wrong, and missing lunch if they are more wrong. Detention is also a good punishment—and beneficial to management, as it keeps people at work longer.

[Ron Jeffries [e-mail] [SCRUMDEVELOPMENT]]

Damn, this is excellent, and completely in line with the holiday spirit as well.
:)
R

Post by ***@tobymayer.com [SCRUMDEVELOPMENT]
Estimating work once the work is done is great. You will be 100% accurate—and more importantly you will prove that all the previous guesswork was wrong. Telling people they are wrong is a very good way to keep them in their place, and maintain control. So I say go for it. You may also want to introduce a punishment system based on just how wrong they were, say prohibiting a coffee break if a little bit wrong, and missing lunch if they are more wrong. Detention is also a good punishment—and beneficial to management, as it keeps people at work longer.

Ron Jeffries
www.XProgramming.com
It's true hard work never killed anybody, but I figure, why take the chance?
-- Ronald Reagan

[Yves Hanoulle [e-mail] [SCRUMDEVELOPMENT]]

Tobias,


lovely way of putting it.


I will steal this.


y

Post by ***@tobymayer.com [SCRUMDEVELOPMENT]
Estimating work once the work is done is great. You will be 100%
accurate—and more importantly you will prove that all the previous
guesswork was wrong. Telling people they are wrong is a very good way to
keep them in their place, and maintain control. So I say go for it. You may
also want to introduce a punishment system based on just how wrong they
were, say prohibiting a coffee break if a little bit wrong, and missing
lunch if they are more wrong. Detention is also a good punishment—and
beneficial to management, as it keeps people at work longer.

--
Yves Hanoulle
Phone [phone]


Skype YvesHanoulle


Blog: www.Hanoulle.be <http://www.hanoulle.be/>


Coaching Question Of the Day: http://twitter.com/Retroflection

[Markus Gaertner [e-mail] [SCRUMDEVELOPMENT]]

I think you forgot the </sarcasm> end note, Tobias.

Best
Markus

Scaling Agile as if you meant it: http://www.scaledprinciples.org
--
Dipl.-Inform. Markus Gaertner
Author of ATDD by Example - A Practical Guide to Acceptance Test-Driven
Development

http://www.shino.de/blog
http://www.mgaertne.de
http://www.it-agile.de

Post by ***@tobymayer.com [SCRUMDEVELOPMENT]
Estimating work once the work is done is great. You will be 100%
accurate—and more importantly you will prove that all the previous
guesswork was wrong. Telling people they are wrong is a very good way to
keep them in their place, and maintain control. So I say go for it. You may
also want to introduce a punishment system based on just how wrong they
were, say prohibiting a coffee break if a little bit wrong, and missing
lunch if they are more wrong. Detention is also a good punishment—and
beneficial to management, as it keeps people at work longer.

[[e-mail] [SCRUMDEVELOPMENT]]

It wasn't intended as sarcasm. It was intended as truth-speaking.

[Ron Jeffries [e-mail] [SCRUMDEVELOPMENT]]

Tobias,

Post by ***@gmail.com [SCRUMDEVELOPMENT]
It wasn't intended as sarcasm. It was intended as truth-speaking.

I’d expect truth-speaking to involve speaking truth.

Ron Jeffries
www.RonJeffries.com <http://ronjeffries.com/>
Wisdom begins when we learn the difference between "that makes no sense" and "I don't understand". -- Mary Doria Russell

[[e-mail] [SCRUMDEVELOPMENT]]

Post by Ron Jeffries ***@acm.org [SCRUMDEVELOPMENT]

Post by ***@gmail.com [SCRUMDEVELOPMENT]
It wasn't intended as sarcasm. It was intended as truth-speaking.

I’d expect truth-speaking to involve speaking truth.

Yes.

Estimating work once the work is done...will be 100% accurate
True.

you will prove that all the previous guesswork was wrong.
True.

Telling people they are wrong is a very good way to keep them in their place, and maintain control.
True.

Detention is also a good punishment
True.

—and beneficial to management
Dubiously true—it depends on how one measures "benefit".

as it keeps people at work longer.
True.

The no-lunch part was non-serious suggestion. I guess that part could be interpreted as sarcasm. It was intended to highlight folly.

[Ron Jeffries [e-mail] [SCRUMDEVELOPMENT]]

I stand corrected.

Post by ***@gmail.com [SCRUMDEVELOPMENT]

Post by Ron Jeffries ***@acm.org [SCRUMDEVELOPMENT]

Post by ***@gmail.com [SCRUMDEVELOPMENT]
It wasn't intended as sarcasm. It was intended as truth-speaking.

I’d expect truth-speaking to involve speaking truth.

Yes.
Estimating work once the work is done...will be 100% accurate
True.
you will prove that all the previous guesswork was wrong.
True.
Telling people they are wrong is a very good way to keep them in their place, and maintain control.
True.
Detention is also a good punishment
True.
—and beneficial to management
Dubiously true—it depends on how one measures "benefit".
as it keeps people at work longer.
True.
The no-lunch part was non-serious suggestion. I guess that part could be interpreted as sarcasm. It was intended to highlight folly.

I sort of thought that was the point of the entire remark. I regret not understanding immediately.

Ron Jeffries
www.ronjeffries.com <http://ronjeffries.com/>
Sometimes you just have to stop holding on with both hands, both feet, and your tail, to get someplace better.
Of course you might plummet to the earth and die, but probably not: you were made for this.

[Christofer Jennings [e-mail] [SCRUMDEVELOPMENT]]

Hi All,


Do you do hours estimation for tasks in stories?


I don’t mean to imply estimating hours is a bad thing all the time. I just think it’s often not worth the effort. That is, it’s often wasteful.


Simply looking at a well run task board makes the hours burndown seem unnecessary. Knowing the velocity of the team, the size of the stories, the time remaining, and spread of task tickets on the board gives me an immediate gestalt of progress. The team sees the board and can tell me if they think “all that stuff” will be done by sprint end, or if they need to add/remove scope. None of that requires hours, imho.


I’ve come to see hours estimation as optional. The Agile Manifesto principle "Simplicity--the art of maximizing the amount of work not done--is essential” tells me that if it’s not essential then it’s best not done. (aka Lean muda)


My experience is that doing the hours estimation is useful for teams to get good at estimating how much work there is. It’s a kind of sanity check during planning to see that the dev team is not under or over capacity. It also gives a nice way to have a burndown chart. But it brings up other things that work against the team, even in early formation of the team. For example, hours are often specific to individuals and their background so estimating hours leads to assigning tasks. When a team is estimating, developers haggle about the hours. The haggling can be productive but is also emotionally draining because people may feel like heroes and peasants. Or people may simply say, “well, he knows it takes 2 hours and I don’t, so, whatever”. Then, since the hours are person-specific, the tasks need to be assigned. Etc.


So I’m wondering. How common is it to just not use hours estimation?


Thanks!
-Chris

[Saravana Bharathi [e-mail] [SCRUMDEVELOPMENT]]

We do estimation of hours for the tasks - by whoever picks the task. Whatever the number he comes up with, no questions asked. This is not for tracking individuals, rather for the team to get a feel of progress in the sprint. We also use hours burn down.


Thanks
Saravana Bharathi.


Sent from my iPhone

Post by Christofer Jennings ***@gmail.com [SCRUMDEVELOPMENT]
Hi All,
Do you do hours estimation for tasks in stories?
I don’t mean to imply estimating hours is a bad thing all the time. I just think it’s often not worth the effort. That is, it’s often wasteful.
Simply looking at a well run task board makes the hours burndown seem unnecessary. Knowing the velocity of the team, the size of the stories, the time remaining, and spread of task tickets on the board gives me an immediate gestalt of progress. The team sees the board and can tell me if they think “all that stuff” will be done by sprint end, or if they need to add/remove scope. None of that requires hours, imho.
I’ve come to see hours estimation as optional. The Agile Manifesto principle "Simplicity--the art of maximizing the amount of work not done--is essential” tells me that if it’s not essential then it’s best not done. (aka Lean muda)
My experience is that doing the hours estimation is useful for teams to get good at estimating how much work there is. It’s a kind of sanity check during planning to see that the dev team is not under or over capacity. It also gives a nice way to have a burndown chart. But it brings up other things that work against the team, even in early formation of the team. For example, hours are often specific to individuals and their background so estimating hours leads to assigning tasks. When a team is estimating, developers haggle about the hours. The haggling can be productive but is also emotionally draining because people may feel like heroes and peasants. Or people may simply say, “well, he knows it takes 2 hours and I don’t, so, whatever”. Then, since the hours are person-specific, the tasks need to be assigned. Etc.
So I’m wondering. How common is it to just not use hours estimation?
Thanks!
-Chris

[Christofer Jennings [e-mail] [SCRUMDEVELOPMENT]]

Thanks Saravana!


It seems like your approach requires that the person who did the estimate also does the work. And it sounds like individuals do work rather than, e.g., pairing or swarming work. Is that right? 
. If so, I’d think the team dynamics could be hurt. Do you see the team members working together?


- Chris

Post by Saravana Bharathi ***@agilekarma.com [SCRUMDEVELOPMENT]
We do estimation of hours for the tasks - by whoever picks the task. Whatever the number he comes up with, no questions asked. This is not for tracking individuals, rather for the team to get a feel of progress in the sprint. We also use hours burn down.
Thanks
Saravana Bharathi.
Sent from my iPhone

Post by Christofer Jennings ***@gmail.com [SCRUMDEVELOPMENT]
Hi All,
Do you do hours estimation for tasks in stories?
I don’t mean to imply estimating hours is a bad thing all the time. I just think it’s often not worth the effort. That is, it’s often wasteful.
Simply looking at a well run task board makes the hours burndown seem unnecessary. Knowing the velocity of the team, the size of the stories, the time remaining, and spread of task tickets on the board gives me an immediate gestalt of progress. The team sees the board and can tell me if they think “all that stuff” will be done by sprint end, or if they need to add/remove scope. None of that requires hours, imho.
I’ve come to see hours estimation as optional. The Agile Manifesto principle "Simplicity--the art of maximizing the amount of work not done--is essential” tells me that if it’s not essential then it’s best not done. (aka Lean muda)
My experience is that doing the hours estimation is useful for teams to get good at estimating how much work there is. It’s a kind of sanity check during planning to see that the dev team is not under or over capacity. It also gives a nice way to have a burndown chart. But it brings up other things that work against the team, even in early formation of the team. For example, hours are often specific to individuals and their background so estimating hours leads to assigning tasks. When a team is estimating, developers haggle about the hours. The haggling can be productive but is also emotionally draining because people may feel like heroes and peasants. Or people may simply say, “well, he knows it takes 2 hours and I don’t, so, whatever”. Then, since the hours are person-specific, the tasks need to be assigned. Etc.
So I’m wondering. How common is it to just not use hours estimation?
Thanks!
-Chris

[Neil Cruz [e-mail] [SCRUMDEVELOPMENT]]

Hi, Chris --


In my so-far 3 professional positions as a scrum master within the past 3 years, my teams have used hours estimation. I've seen it go as granular as 1 hour; but I think it's good enough as either full-day (6 hour), half-day (3 hour), or 2 hour tasks. I.e., it's not worth the additional strain to go to 1-hour increments from a SM perspective.


(I have heard from a former colleague that from a Dev perspective, to be as accurate to the 15min granularity.)


Neil Cruz, CSM, PSM I




On Dec 28, 2014, at 11:09 AM, Christofer Jennings ***@gmail.com [SCRUMDEVELOPMENT] <***@yahoogroups.com> wrote:


Hi All,


Do you do hours estimation for tasks in stories?


I don’t mean to imply estimating hours is a bad thing all the time. I just think it’s often not worth the effort. That is, it’s often wasteful.


Simply looking at a well run task board makes the hours burndown seem unnecessary. Knowing the velocity of the team, the size of the stories, the time remaining, and spread of task tickets on the board gives me an immediate gestalt of progress. The team sees the board and can tell me if they think “all that stuff” will be done by sprint end, or if they need to add/remove scope. None of that requires hours, imho.


I’ve come to see hours estimation as optional. The Agile Manifesto principle "Simplicity--the art of maximizing the amount of work not done--is essential” tells me that if it’s not essential then it’s best not done. (aka Lean muda)


My experience is that doing the hours estimation is useful for teams to get good at estimating how much work there is. It’s a kind of sanity check during planning to see that the dev team is not under or over capacity. It also gives a nice way to have a burndown chart. But it brings up other things that work against the team, even in early formation of the team. For example, hours are often specific to individuals and their background so estimating hours leads to assigning tasks. When a team is estimating, developers haggle about the hours. The haggling can be productive but is also emotionally draining because people may feel like heroes and peasants. Or people may simply say, “well, he knows it takes 2 hours and I don’t, so, whatever”. Then, since the hours are person-specific, the tasks need to be assigned. Etc.


So I’m wondering. How common is it to just not use hours estimation?


Thanks!
-Chris

[Adam Sroka [e-mail] [SCRUMDEVELOPMENT]]

In his book Mike Cohn advocates using points to estimate stories,
decomposing them into tasks, and using ideal time to estimate tasks. I have
seen that approach used by a few teams.

In general, my feeling is that this takes a lot of time during planning to
do well. It is important to spend that time discussing what you will
actually do and not just assigning values to canned tasks like "Code,"
"Test," etc. However, the value from that conversation comes mostly from
the discussion of what those tasks are and not from the numbers. If you
need to cut something out to preserve time and/or attention the numbers are
what you should cut.

Kent Beck has also advocated for using ideal time to estimate stories. The
notion of a day is something that people understand. You just have to be
clear that ideal days are not calendar days - there will be various factors
that allow you to complete some number of ideal days of work in some,
generally larger, number of working days. As long as this is communicated
clearly and the number of days for each story is relatively small (No more
than half the length of your Sprint as an absolute maximum, ideally much
less than that) this is pretty effective and takes less time to plan.

My preference is for something more like what Ron Jeffries recommends which
is sort of a cross between ideal days and no estimates. Essentially, you
spend the time you have available for planning discussing the value of
stories and breaking them smaller and smaller until they are each about one
ideal day worth. That may sound impossible at first, but with some practice
it goes pretty smoothly. Again, you aren't going to get a story done every
single day, but you are going to demonstrate regular progress every week.

Post by Christofer Jennings ***@gmail.com [SCRUMDEVELOPMENT]
Hi All,
Do you do hours estimation for tasks in stories?
I don’t mean to imply estimating hours is a bad thing all the time. I just
think it’s often not worth the effort. That is, it’s often wasteful.
Simply looking at a well run task board makes the hours burndown seem
unnecessary. Knowing the velocity of the team, the size of the stories, the
time remaining, and spread of task tickets on the board gives me an
immediate gestalt of progress. The team sees the board and can tell me if
they think “all that stuff” will be done by sprint end, or if they need to
add/remove scope. None of that requires hours, imho.
I’ve come to see hours estimation as optional. The Agile Manifesto
principle "Simplicity--the art of maximizing the amount of work not
done--is essential” tells me that if it’s not essential then it’s best not
done. (aka Lean muda)
My experience is that doing the hours estimation is useful for teams to
get good at estimating how much work there is. It’s a kind of sanity check
during planning to see that the dev team is not under or over capacity. It
also gives a nice way to have a burndown chart. But it brings up other
things that work against the team, even in early formation of the team. For
example, hours are often specific to individuals and their background so
estimating hours leads to assigning tasks. When a team is estimating,
developers haggle about the hours. The haggling can be productive but is
also emotionally draining because people may feel like heroes and peasants.
Or people may simply say, “well, he knows it takes 2 hours and I don’t, so,
whatever”. Then, since the hours are person-specific, the tasks need to be
assigned. Etc.
So I’m wondering. How common is it to just not use hours estimation?
Thanks!
-Chris

[Adam Sroka [e-mail] [SCRUMDEVELOPMENT]]

P.S. I forgot to say that ideal times for tasks, as described by Mike Cohn,
are estimated in units of hours. The other approaches are in days.

Post by Adam Sroka ***@gmail.com [SCRUMDEVELOPMENT]
In his book Mike Cohn advocates using points to estimate stories,
decomposing them into tasks, and using ideal time to estimate tasks. I have
seen that approach used by a few teams.
In general, my feeling is that this takes a lot of time during planning to
do well. It is important to spend that time discussing what you will
actually do and not just assigning values to canned tasks like "Code,"
"Test," etc. However, the value from that conversation comes mostly from
the discussion of what those tasks are and not from the numbers. If you
need to cut something out to preserve time and/or attention the numbers are
what you should cut.
Kent Beck has also advocated for using ideal time to estimate stories. The
notion of a day is something that people understand. You just have to be
clear that ideal days are not calendar days - there will be various factors
that allow you to complete some number of ideal days of work in some,
generally larger, number of working days. As long as this is communicated
clearly and the number of days for each story is relatively small (No more
than half the length of your Sprint as an absolute maximum, ideally much
less than that) this is pretty effective and takes less time to plan.
My preference is for something more like what Ron Jeffries recommends
which is sort of a cross between ideal days and no estimates. Essentially,
you spend the time you have available for planning discussing the value of
stories and breaking them smaller and smaller until they are each about one
ideal day worth. That may sound impossible at first, but with some practice
it goes pretty smoothly. Again, you aren't going to get a story done every
single day, but you are going to demonstrate regular progress every week.

Post by Christofer Jennings ***@gmail.com [SCRUMDEVELOPMENT]
Hi All,
Do you do hours estimation for tasks in stories?
I don’t mean to imply estimating hours is a bad thing all the time. I
just think it’s often not worth the effort. That is, it’s often wasteful.
Simply looking at a well run task board makes the hours burndown seem
unnecessary. Knowing the velocity of the team, the size of the stories, the
time remaining, and spread of task tickets on the board gives me an
immediate gestalt of progress. The team sees the board and can tell me if
they think “all that stuff” will be done by sprint end, or if they need to
add/remove scope. None of that requires hours, imho.
I’ve come to see hours estimation as optional. The Agile Manifesto
principle "Simplicity--the art of maximizing the amount of work not
done--is essential” tells me that if it’s not essential then it’s best not
done. (aka Lean muda)
My experience is that doing the hours estimation is useful for teams to
get good at estimating how much work there is. It’s a kind of sanity check
during planning to see that the dev team is not under or over capacity. It
also gives a nice way to have a burndown chart. But it brings up other
things that work against the team, even in early formation of the team. For
example, hours are often specific to individuals and their background so
estimating hours leads to assigning tasks. When a team is estimating,
developers haggle about the hours. The haggling can be productive but is
also emotionally draining because people may feel like heroes and peasants.
Or people may simply say, “well, he knows it takes 2 hours and I don’t, so,
whatever”. Then, since the hours are person-specific, the tasks need to be
assigned. Etc.
So I’m wondering. How common is it to just not use hours estimation?
Thanks!
-Chris

[[e-mail] [SCRUMDEVELOPMENT]]

Hi Chris.

Simply looking at a well run task board makes the hours burndown seem unnecessary...

I agree. I encouraged teams to abandon hours estimation in 2005, within my first year of using Scrum. I've never used or promoted the idea since, and have no regrets. I find most estimation to be (at best) minimally useful, but this form in particular is pure waste. Team's freed of this practice are usually visibly relieved, as if a burden of process has been lifted from their backs.

I also no longer encourage the use of story point estimates for much the same reason, preferring instead to get a sense of a team's capacity by simply counting either average cycle time per story, or average number of stories per sprint. The principle you quote: "Simplicity--the art of maximizing the amount of work not done--is essential” is a good one to follow, perhaps especially in the practice of estimation.

Tobias

[thierry henrio [e-mail] [SCRUMDEVELOPMENT]]

Hello Chris

Post by ***@gmail.com [SCRUMDEVELOPMENT]
Hi Chris.

Post by Christofer Jennings ***@gmail.com [SCRUMDEVELOPMENT]
Simply looking at a well run task board makes the hours burndown seem

unnecessary...
I agree. I encouraged teams to abandon hours estimation in 2005, within my
first year of using Scrum. I've never used or promoted the idea since, and
have no regrets.

I also no longer encourage the use of story point estimates for much the

Post by ***@gmail.com [SCRUMDEVELOPMENT]
same reason
I'm with Tobias ( with a 4 years lag, if that matters )

I have two enablers

*trust*
This works better with trust

Trust is gained when

* you release working software
* you solve customer problems

And of course, in a timely manner™ :)

*culture*
This works better when there is a culture a solving problems
For a developer, it is ... write so virtuous test and code?
For his leader, it is to ???

Tell us what your leader is asking ?

*( craft*
This is an optional one, if you do code
And this is the one I use to drive the two others )

?, Thierry

[Michael Kirby [e-mail] [SCRUMDEVELOPMENT]]

For small projects that seems reasonable.

But for larger ones where other engineering and business processes depend on the estimation I am not sure you can get away from it entirely.

We try to use hours agains a rough budget for prioritized "features" (really groups of stories)

Some go over, some go under and it usually balances out in the end, but new stories and story growth can be prioritized globally across all the scrums.

Mike

Sent from my iPhone

Post by thierry henrio ***@gmail.com [SCRUMDEVELOPMENT]
Hello Chris

Post by ***@gmail.com [SCRUMDEVELOPMENT]
Hi Chris.

Simply looking at a well run task board makes the hours burndown seem unnecessary...

I agree. I encouraged teams to abandon hours estimation in 2005, within my first year of using Scrum. I've never used or promoted the idea since, and have no regrets.
I also no longer encourage the use of story point estimates for much the same reason

I'm with Tobias ( with a 4 years lag, if that matters )
I have two enablers
trust
This works better with trust
Trust is gained when
* you release working software
* you solve customer problems
And of course, in a timely manner™ :)
culture
This works better when there is a culture a solving problems
For a developer, it is ... write so virtuous test and code?
For his leader, it is to ???
Tell us what your leader is asking ?
( craft
This is an optional one, if you do code
And this is the one I use to drive the two others )
?, Thierry

[Markus Gärtner [e-mail] [SCRUMDEVELOPMENT]]

Hi Michael,

why do these others depend on (gu)estimates?

Best Markus

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

http://www.shino.de/blog
http://www.mgaertne.de
http://www.it-agile.de

Post by Michael Kirby ***@gmail.com [SCRUMDEVELOPMENT]
For small projects that seems reasonable.
But for larger ones where other engineering and business processes depend on the estimation I am not sure you can get away from it entirely.
We try to use hours agains a rough budget for prioritized "features" (really groups of stories)
Some go over, some go under and it usually balances out in the end, but new stories and story growth can be prioritized globally across all the scrums.
Mike
Sent from my iPhone

Post by thierry henrio ***@gmail.com [SCRUMDEVELOPMENT]
Hello Chris

Post by ***@gmail.com [SCRUMDEVELOPMENT]
Hi Chris.

Simply looking at a well run task board makes the hours burndown seem unnecessary...

I agree. I encouraged teams to abandon hours estimation in 2005, within my first year of using Scrum. I've never used or promoted the idea since, and have no regrets.
I also no longer encourage the use of story point estimates for much the same reason

I'm with Tobias ( with a 4 years lag, if that matters )
I have two enablers
trust
This works better with trust
Trust is gained when
* you release working software
* you solve customer problems
And of course, in a timely manner™ :)
culture
This works better when there is a culture a solving problems
For a developer, it is ... write so virtuous test and code?
For his leader, it is to ???
Tell us what your leader is asking ?
( craft
This is an optional one, if you do code
And this is the one I use to drive the two others )
?, Thierry

[Michael Kirby [e-mail] [SCRUMDEVELOPMENT]]

It is more about trying to size the release so hardware or business processes or systems are built ( or not built)

Typically we do a capacity/estimate model at three progressively detailed levels.

A high level business estimate along with head count costs.

Then a feature breakdown and (high/medium/low) for the features. (Against an organizational capacity based on prior release deliveries)

And then story breakdown and hour/point estimate, and iteration / task for the current estimate.

At each phase we prioritize and eliminate things that don't fit (or add things that do)

Overall there are about 25 scrums or so that participate, across 3 continents.

Mike

Sent from my iPhone

Post by Markus Gärtner ***@gmail.com [SCRUMDEVELOPMENT]
http://www.shino.de/blog
http://www.mgaertne.de
http://www.it-agile.de

Post by Michael Kirby ***@gmail.com [SCRUMDEVELOPMENT]
For small projects that seems reasonable.
But for larger ones where other engineering and business processes depend on the estimation I am not sure you can get away from it entirely.
We try to use hours agains a rough budget for prioritized "features" (really groups of stories)
Some go over, some go under and it usually balances out in the end, but new stories and story growth can be prioritized globally across all the scrums.
Mike
Sent from my iPhone

Post by thierry henrio ***@gmail.com [SCRUMDEVELOPMENT]
Hello Chris

Post by ***@gmail.com [SCRUMDEVELOPMENT]
Hi Chris.

Simply looking at a well run task board makes the hours burndown seem unnecessary...

I agree. I encouraged teams to abandon hours estimation in 2005, within my first year of using Scrum. I've never used or promoted the idea since, and have no regrets.
I also no longer encourage the use of story point estimates for much the same reason

I'm with Tobias ( with a 4 years lag, if that matters )
I have two enablers
trust
This works better with trust
Trust is gained when
* you release working software
* you solve customer problems
And of course, in a timely manner™ :)
culture
This works better when there is a culture a solving problems
For a developer, it is ... write so virtuous test and code?
For his leader, it is to ???
Tell us what your leader is asking ?
( craft
This is an optional one, if you do code
And this is the one I use to drive the two others )
?, Thierry

[Markus Gärtner [e-mail] [SCRUMDEVELOPMENT]]

Sounds like you are doing a lot of speculation there. The main mechanism to do most of these things is the Product Backlog. Even with 25 teams, I would work on splitting the Product Backlog into three different requirement areas, one for each of the continents, and then have more local teams work out the details, what's in scope for the next three months, and what's out of scope.

Best Markus

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

http://www.shino.de/blog
http://www.mgaertne.de
http://www.it-agile.de

Post by Michael Kirby ***@gmail.com [SCRUMDEVELOPMENT]
It is more about trying to size the release so hardware or business processes or systems are built ( or not built)
Typically we do a capacity/estimate model at three progressively detailed levels.
A high level business estimate along with head count costs.
Then a feature breakdown and (high/medium/low) for the features. (Against an organizational capacity based on prior release deliveries)
And then story breakdown and hour/point estimate, and iteration / task for the current estimate.
At each phase we prioritize and eliminate things that don't fit (or add things that do)
Overall there are about 25 scrums or so that participate, across 3 continents.
Mike
Sent from my iPhone

Post by Markus Gärtner ***@gmail.com [SCRUMDEVELOPMENT]
http://www.shino.de/blog
http://www.mgaertne.de
http://www.it-agile.de

Post by Michael Kirby ***@gmail.com [SCRUMDEVELOPMENT]
For small projects that seems reasonable.
But for larger ones where other engineering and business processes depend on the estimation I am not sure you can get away from it entirely.
We try to use hours agains a rough budget for prioritized "features" (really groups of stories)
Some go over, some go under and it usually balances out in the end, but new stories and story growth can be prioritized globally across all the scrums.
Mike
Sent from my iPhone

Post by thierry henrio ***@gmail.com [SCRUMDEVELOPMENT]
Hello Chris

Post by ***@gmail.com [SCRUMDEVELOPMENT]
Hi Chris.

Simply looking at a well run task board makes the hours burndown seem unnecessary...

I agree. I encouraged teams to abandon hours estimation in 2005, within my first year of using Scrum. I've never used or promoted the idea since, and have no regrets.
I also no longer encourage the use of story point estimates for much the same reason

I'm with Tobias ( with a 4 years lag, if that matters )
I have two enablers
trust
This works better with trust
Trust is gained when
* you release working software
* you solve customer problems
And of course, in a timely manner™ :)
culture
This works better when there is a culture a solving problems
For a developer, it is ... write so virtuous test and code?
For his leader, it is to ???
Tell us what your leader is asking ?
( craft
This is an optional one, if you do code
And this is the one I use to drive the two others )
?, Thierry

[Cass Dalton [e-mail] [SCRUMDEVELOPMENT]]

Personally, I'm against decomposing to or estimating in hours. Estimating
in hours doesn't really provide any benefit to the team over estimating in
days/points or story counting. And estimating in hours leads to tracking
in hours which is micromanagement. Working in units of hours distracts
from the focus of the team. Estimation is a means to an end. The end is
helping the team get better at delivery. Estimating in hours tends to make
people focus on the estimates as an end in themselves. It also leads to
external micromanagement. When managers see all those hour estimates, they
see something that they can manage. That leads to management trying to get
the team better at estimating instead of getting the team better at
delivery. When a team misses a delivery date, the tendency will be to
figure out how to improve the estimates (a very hard and irrelevant job)
instead of improving the ability to deliver or remove systemic impediments
(much more important).


-Cass

Post by Michael Kirby ***@gmail.com [SCRUMDEVELOPMENT]
It is more about trying to size the release so hardware or business
processes or systems are built ( or not built)
Typically we do a capacity/estimate model at three progressively detailed levels.
A high level business estimate along with head count costs.
Then a feature breakdown and (high/medium/low) for the features. (Against
an organizational capacity based on prior release deliveries)
And then story breakdown and hour/point estimate, and iteration / task for
the current estimate.
At each phase we prioritize and eliminate things that don't fit (or add things that do)
Overall there are about 25 scrums or so that participate, across 3 continents.
Mike
Sent from my iPhone
http://www.shino.de/blog
http://www.mgaertne.de
http://www.it-agile.de
For small projects that seems reasonable.
But for larger ones where other engineering and business processes depend
on the estimation I am not sure you can get away from it entirely.
We try to use hours agains a rough budget for prioritized "features"
(really groups of stories)
Some go over, some go under and it usually balances out in the end, but
new stories and story growth can be prioritized globally across all the
scrums.
Mike
Sent from my iPhone
Hello Chris

Post by ***@gmail.com [SCRUMDEVELOPMENT]
Hi Chris.

Post by Christofer Jennings ***@gmail.com [SCRUMDEVELOPMENT]
Simply looking at a well run task board makes the hours burndown seem

unnecessary...
I agree. I encouraged teams to abandon hours estimation in 2005, within
my first year of using Scrum. I've never used or promoted the idea since,
and have no regrets.

I also no longer encourage the use of story point estimates for much the

Post by ***@gmail.com [SCRUMDEVELOPMENT]
same reason
I'm with Tobias ( with a 4 years lag, if that matters )

I have two enablers
*trust*
This works better with trust
Trust is gained when
* you release working software
* you solve customer problems
And of course, in a timely manner™ :)
*culture*
This works better when there is a culture a solving problems
For a developer, it is ... write so virtuous test and code?
For his leader, it is to ???
Tell us what your leader is asking ?
*( craft*
This is an optional one, if you do code
And this is the one I use to drive the two others )
?, Thierry

[Christofer Jennings [e-mail] [SCRUMDEVELOPMENT]]

Hi Cass,


Well said. I see similar things. 
 Actually, I’ll admit I’ve *done* similar things!


As an SM I’ve pushed people to estimate and track hours and used a burndown, and then seen the burndown become better but still ended up with stories that weren’t done.


I’ve also been a developer asked to track hours to a burndown because the sprint burndown was being used by management to track progress, and given in to tracking my hours to the burndown even though it didn’t really help me or anyone know if the story would be done.


I think these reactions are just basic human nature. In the first case I was learning how to manage with scrum. In the second I was taking a path of least resistance so I could get back to working on the features. I now do my best to avoid both cases, but I can’t always control enough to keep away from resorting to path of least resistance behavior—it’s just prioritizing my effort after all.


I’ll restate though that I’m not against hours estimation of tasks if it helps the team know how the work will get done, and how much can be in a sprint (assuming scrum). I just don’t think it’s the *only* way. What you say about managers using the hours estimation alludes to something I think is key. The dev team’s estimate and sprint tracking is up to the dev team. It’s a way for them to know where they’re at, and a tool to help them communicate commitments and progress. If whatever they are doing is used by management for something else, like cross organizational concerns, that could be a red flag. It means the dev team loses control of their tools. I means they lose some ownership.


-Chris

Personally, I'm against decomposing to or estimating in hours. Estimating in hours doesn't really provide any benefit to the team over estimating in days/points or story counting. And estimating in hours leads to tracking in hours which is micromanagement. Working in units of hours distracts from the focus of the team. Estimation is a means to an end. The end is helping the team get better at delivery. Estimating in hours tends to make people focus on the estimates as an end in themselves. It also leads to external micromanagement. When managers see all those hour estimates, they see something that they can manage. That leads to management trying to get the team better at estimating instead of getting the team better at delivery. When a team misses a delivery date, the tendency will be to figure out how to improve the estimates (a very hard and irrelevant job) instead of improving the ability to deliver or remove systemic impediments (much more important).
-Cass
It is more about trying to size the release so hardware or business processes or systems are built ( or not built)
Typically we do a capacity/estimate model at three progressively detailed levels.
A high level business estimate along with head count costs.
Then a feature breakdown and (high/medium/low) for the features. (Against an organizational capacity based on prior release deliveries)
And then story breakdown and hour/point estimate, and iteration / task for the current estimate.
At each phase we prioritize and eliminate things that don't fit (or add things that do)
Overall there are about 25 scrums or so that participate, across 3 continents.
Mike
Sent from my iPhone

http://www.shino.de/blog <http://www.shino.de/blog>
http://www.mgaertne.de <http://www.mgaertne.de/>
http://www.it-agile.de <http://www.it-agile.de/>

Post by Michael Kirby ***@gmail.com [SCRUMDEVELOPMENT]
For small projects that seems reasonable.
But for larger ones where other engineering and business processes depend on the estimation I am not sure you can get away from it entirely.
We try to use hours agains a rough budget for prioritized "features" (really groups of stories)
Some go over, some go under and it usually balances out in the end, but new stories and story growth can be prioritized globally across all the scrums.
Mike
Sent from my iPhone

Post by thierry henrio ***@gmail.com [SCRUMDEVELOPMENT]
Hello Chris
Hi Chris.

Simply looking at a well run task board makes the hours burndown seem unnecessary...

I agree. I encouraged teams to abandon hours estimation in 2005, within my first year of using Scrum. I've never used or promoted the idea since, and have no regrets.
I also no longer encourage the use of story point estimates for much the same reason
I'm with Tobias ( with a 4 years lag, if that matters )
I have two enablers
trust
This works better with trust
Trust is gained when
* you release working software
* you solve customer problems
And of course, in a timely manner™ :)
culture
This works better when there is a culture a solving problems
For a developer, it is ... write so virtuous test and code?
For his leader, it is to ???
Tell us what your leader is asking ?
( craft
This is an optional one, if you do code
And this is the one I use to drive the two others )
?, Thierry

[Cass Dalton [e-mail] [SCRUMDEVELOPMENT]]

I personally dislike the entire idea of breaking stories into tasks. It's
similar to the reason I don't like counting hours. Stories are first class

members of the PBL. Tasks are not. Stories have fairly strict and
consistent criteria for what makes a "good" story (direct tie to
customer/user value, end-to-end functionality, etc), tasks do not. If you
allow developers, especially those getting used to agile philosophies vs a
traditional mindset, you will get larger stories that are decomposed into
skill based or archiecture based tasks with some integration tasks at the
end. So tasks are an easy way for waterfall to hide in agile. We decompose
down to 2-3 day stories. We don't spend time estimating hours. This saves
us hours every planning meeting. For every story, we ask ourselves if the
story is more than a couple of days or if it's too big or complex. If
we're not sure, we (as a team) talk through the definition of done and the
expectations of the story and what it would take to get there. THIS
CONVERSATION IS THE MOST IMPORTANT BENEFIT OF ESTIMATION and it can be
achieved without estimating to hours. If we feel that the story is too
big, we talk through how to split it into smaller stories that still have
user/customer value (and buying down risk is part of customer value).


If a sprint doesn't go as well as we hoped, or if someone felt like a story
took longer than it should have (notice we are still not comparing actual
hours to estimated hours) we talk through what happened and how we could
have done it better in the retro. These are the conversations that are
facilitated by hour estimation and we have them all without the time
consuming estimation or comparison to actuals. Not only is it hard to
estimate "correctly" in hours, it's also very hard to really track hours
without the team really micromanaging themselves.


We are so much more efficient by just counting stories. We track each
refined story as a single story point. And if there is a story on the
backlog that is not going into the current sprint that is too big, we note
it by giving it >1 story point. But we don't let >1 point stories into a
sprint. This actually results in a pretty consistent velocity metric
because all the stories are, on average, the same size. Trying to get good
at estmiating EVERY SINGLE STORY is inefficient micromanagement. Trying to
get good at estimating an average story provides long term benefit and
facilitates team improvement.

Post by Christofer Jennings ***@gmail.com [SCRUMDEVELOPMENT]
Hi Cass,
Well said. I see similar things. 
 Actually, I’ll admit I’ve *done*
similar things!
As an SM I’ve pushed people to estimate and track hours and used a
burndown, and then seen the burndown become better but still ended up with
stories that weren’t done.
I’ve also been a developer asked to track hours to a burndown because the
sprint burndown was being used by management to track progress, and given
in to tracking my hours to the burndown even though it didn’t really help
me or anyone know if the story would be done.
I think these reactions are just basic human nature. In the first case I
was learning how to manage with scrum. In the second I was taking a path of
least resistance so I could get back to working on the features. I now do
my best to avoid both cases, but I can’t always control enough to keep away
from resorting to path of least resistance behavior—it’s just prioritizing
my effort after all.
I’ll restate though that I’m not against hours estimation of tasks if it
helps the team know how the work will get done, and how much can be in a
sprint (assuming scrum). I just don’t think it’s the *only* way. What you
say about managers using the hours estimation alludes to something I think
is key. The dev team’s estimate and sprint tracking is up to the dev team.
It’s a way for them to know where they’re at, and a tool to help them
communicate commitments and progress. If whatever they are doing is used by
management for something else, like cross organizational concerns, that
could be a red flag. It means the dev team loses control of their tools. I
means they lose some ownership.
-Chris
Personally, I'm against decomposing to or estimating in hours.
Estimating in hours doesn't really provide any benefit to the team over
estimating in days/points or story counting. And estimating in hours leads
to tracking in hours which is micromanagement. Working in units of hours
distracts from the focus of the team. Estimation is a means to an end.
The end is helping the team get better at delivery. Estimating in hours
tends to make people focus on the estimates as an end in themselves. It
also leads to external micromanagement. When managers see all those hour
estimates, they see something that they can manage. That leads to
management trying to get the team better at estimating instead of getting
the team better at delivery. When a team misses a delivery date, the
tendency will be to figure out how to improve the estimates (a very hard
and irrelevant job) instead of improving the ability to deliver or remove
systemic impediments (much more important).
-Cass

Post by Michael Kirby ***@gmail.com [SCRUMDEVELOPMENT]
It is more about trying to size the release so hardware or business
processes or systems are built ( or not built)
Typically we do a capacity/estimate model at three progressively detailed levels.
A high level business estimate along with head count costs.
Then a feature breakdown and (high/medium/low) for the features. (Against
an organizational capacity based on prior release deliveries)
And then story breakdown and hour/point estimate, and iteration / task
for the current estimate.
At each phase we prioritize and eliminate things that don't fit (or add things that do)
Overall there are about 25 scrums or so that participate, across 3 continents.
Mike
Sent from my iPhone
http://www.shino.de/blog
http://www.mgaertne.de
http://www.it-agile.de
For small projects that seems reasonable.
But for larger ones where other engineering and business processes depend
on the estimation I am not sure you can get away from it entirely.
We try to use hours agains a rough budget for prioritized "features"
(really groups of stories)
Some go over, some go under and it usually balances out in the end, but
new stories and story growth can be prioritized globally across all the
scrums.
Mike
Sent from my iPhone
Hello Chris

Post by ***@gmail.com [SCRUMDEVELOPMENT]
Hi Chris.

Post by Christofer Jennings ***@gmail.com [SCRUMDEVELOPMENT]
Simply looking at a well run task board makes the hours burndown seem

unnecessary...
I agree. I encouraged teams to abandon hours estimation in 2005, within
my first year of using Scrum. I've never used or promoted the idea since,
and have no regrets.

I also no longer encourage the use of story point estimates for much the

Post by ***@gmail.com [SCRUMDEVELOPMENT]
same reason
I'm with Tobias ( with a 4 years lag, if that matters )

I have two enablers
*trust*
This works better with trust
Trust is gained when
* you release working software
* you solve customer problems
And of course, in a timely manner™ :)
*culture*
This works better when there is a culture a solving problems
For a developer, it is ... write so virtuous test and code?
For his leader, it is to ???
Tell us what your leader is asking ?
*( craft*
This is an optional one, if you do code
And this is the one I use to drive the two others )
?, Thierry

[[e-mail] [SCRUMDEVELOPMENT]]

I once lead a 100-people dept. to use daily estimation and tracking with the MS project Server for 4 years. the task was identified at hours base which was not a Agile environment.
At the end of 2007, we abandoned the daily estimation and tracking.
that's my big lessons-learning after 4 years' journey which support Cass's.
when I adapt to Agile. I never select task hours estimation in each user story. I only use story points or use-case point.
for me. it is rediculous to estimate 3 hours to write some tests/functions in a user story.
And also, I don't use hours to draw burn-down chart.
I totally agree with Cass.

[Ron Jeffries [e-mail] [SCRUMDEVELOPMENT]]

Michael,

Post by Michael Kirby ***@gmail.com [SCRUMDEVELOPMENT]
We try to use hours agains a rough budget for prioritized "features" (really groups of stories)
Some go over, some go under and it usually balances out in the end, but new stories and story growth can be prioritized globally across all the scrums.

If they average out, why not just count the stories?

Ron Jeffries
www.ronjeffries.com <http://ronjeffries.com/>
Before you contradict an old man, my fair friend, you should endeavor to understand him. - George Santayana

[Michael Kirby [e-mail] [SCRUMDEVELOPMENT]]

It isn't the stories that average out. It is the blocks of related stories that make up a "feature"

Sometimes the stories grow significantly if we run into weird things (technical debt removal is a common issue).

Sometimes the PO gets creative (or they lacked creativity when we started)

And sometimes a block of stories turn out to be much easier than when we scoped it as a block.

In the group I am in now when i first came on board some of the teams were having the PO do the stories, which they were just "taking." Them. No real estimates were done and outcome was variable.

I tried to make the teams take more ownership in the stories. I wanted the teams to commit, and they need to own them to commit to them.

I also find the act of attempting to estimate the stories a very good process for thoroughly thinking through the problem. Similarly tracking effort is a good indicator of something bad happening. Both at an individual level and as a team

Mike

Sent from my iPhone

Post by Markus Gärtner ***@gmail.com [SCRUMDEVELOPMENT]
Michael,

Post by Michael Kirby ***@gmail.com [SCRUMDEVELOPMENT]
We try to use hours agains a rough budget for prioritized "features" (really groups of stories)
Some go over, some go under and it usually balances out in the end, but new stories and story growth can be prioritized globally across all the scrums.

If they average out, why not just count the stories?
Ron Jeffries
www.ronjeffries.com
Before you contradict an old man, my fair friend, you should endeavor to understand him. - George Santayana

[Christofer Jennings [e-mail] [SCRUMDEVELOPMENT]]

Hi Mike,


Has your organization tried anything other than estimating hours on tasks for sprint planning and sprint tracking?


Also, you mentioned 25 scrums. It sounds like they are all required to estimate task hours. If so, what are the larger organizational benefits?


For the sake of dialog, let me assume the process consistency alone *is* the organizational benefit. That could help because similar language could be used across teams. It might even be less efficient for one or another team but more efficient for the whole organization. Is that how you see it or are there other things you consider?


-Chris

Post by Michael Kirby ***@gmail.com [SCRUMDEVELOPMENT]
It isn't the stories that average out. It is the blocks of related stories that make up a "feature"
Sometimes the stories grow significantly if we run into weird things (technical debt removal is a common issue).
Sometimes the PO gets creative (or they lacked creativity when we started)
And sometimes a block of stories turn out to be much easier than when we scoped it as a block.
In the group I am in now when i first came on board some of the teams were having the PO do the stories, which they were just "taking." Them. No real estimates were done and outcome was variable.
I tried to make the teams take more ownership in the stories. I wanted the teams to commit, and they need to own them to commit to them.
I also find the act of attempting to estimate the stories a very good process for thoroughly thinking through the problem. Similarly tracking effort is a good indicator of something bad happening. Both at an individual level and as a team
Mike
Sent from my iPhone

Post by Markus Gärtner ***@gmail.com [SCRUMDEVELOPMENT]
Michael,

Post by Michael Kirby ***@gmail.com [SCRUMDEVELOPMENT]
We try to use hours agains a rough budget for prioritized "features" (really groups of stories)
Some go over, some go under and it usually balances out in the end, but new stories and story growth can be prioritized globally across all the scrums.

If they average out, why not just count the stories?
Ron Jeffries
www.ronjeffries.com <http://ronjeffries.com/>
Before you contradict an old man, my fair friend, you should endeavor to understand him. - George Santayana

[Christofer Jennings [e-mail] [SCRUMDEVELOPMENT]]

Hi Tobias,


I like what you’re saying and have had so many years experience succeeding with it. It’s good to have people/experiences to point to when explaining options to people who don’t think it could possibly work. :)


I’m curious about the no-story-points. It sounds like your teams must do *something* to get stories to similar sizes to track cycle time or stories-per-sprint. Am I right? Or are you able to do those sorts of tracking & estimations without same-sizing the stories?


- Chris

Post by ***@gmail.com [SCRUMDEVELOPMENT]
Hi Chris.

Simply looking at a well run task board makes the hours burndown seem unnecessary...

I agree. I encouraged teams to abandon hours estimation in 2005, within my first year of using Scrum. I've never used or promoted the idea since, and have no regrets. I find most estimation to be (at best) minimally useful, but this form in particular is pure waste. Team's freed of this practice are usually visibly relieved, as if a burden of process has been lifted from their backs.
I also no longer encourage the use of story point estimates for much the same reason, preferring instead to get a sense of a team's capacity by simply counting either average cycle time per story, or average number of stories per sprint. The principle you quote: "Simplicity--the art of maximizing the amount of work not done--is essential” is a good one to follow, perhaps especially in the practice of estimation.
Tobias

[[e-mail] [SCRUMDEVELOPMENT]]

Hi Chris.
I've long had a rule of thumb, which seems to work no matter the sprint length, of 5-10 stories per sprint. Having that as a goal helps teams/POs to small-size stories. But even if stories vary in size, over enough time you can get a good sense of the average. And honestly, does upfront estimation really help? It's better to focus on getting useful work done. I prefer it when teams take on one story at a time (max 2) and swarm to completion. This practice tends to override the need for estimates as the business really is getting frequent delivery of working software.
Tobias


---In ***@yahoogroups.com, <***@...> wrote :

Hi Tobias,

I like what you’re saying and have had so many years experience succeeding with it. It’s good to have people/experiences to point to when explaining options to people who don’t think it could possibly work. :)


I’m curious about the no-story-points. It sounds like your teams must do *something* to get stories to similar sizes to track cycle time or stories-per-sprint. Am I right? Or are you able to do those sorts of tracking & estimations without same-sizing the stories?


- Chris




On Dec 29, 2014, at 12:14 PM, ***@... mailto:***@... [SCRUMDEVELOPMENT] <***@yahoogroups.com mailto:***@yahoogroups.com> wrote:

Hi Chris.

Simply looking at a well run task board makes the hours burndown seem unnecessary...

I agree. I encouraged teams to abandon hours estimation in 2005, within my first year of using Scrum. I've never used or promoted the idea since, and have no regrets. I find most estimation to be (at best) minimally useful, but this form in particular is pure waste. Team's freed of this practice are usually visibly relieved, as if a burden of process has been lifted from their backs.

I also no longer encourage the use of story point estimates for much the same reason, preferring instead to get a sense of a team's capacity by simply counting either average cycle time per story, or average number of stories per sprint. The principle you quote: "Simplicity--the art of maximizing the amount of work not done--is essential” is a good one to follow, perhaps especially in the practice of estimation.

Tobias

[Ron Jeffries [e-mail] [SCRUMDEVELOPMENT]]

I decided to write an article about this. Here it is:

http://ronjeffries.com/articles/2015-01-02-hours-estimation/article.html <http://ronjeffries.com/articles/2015-01-02-hours-estimation/article.html>

Ron Jeffries
www.XProgramming.com <http://www.xprogramming.com/>
I'm not bad, I'm just drawn that way. -- Jessica Rabbit

[Adrian Howard [e-mail] [SCRUMDEVELOPMENT]]

Post by Ron Jeffries ***@acm.org [SCRUMDEVELOPMENT]
http://ronjeffries.com/articles/2015-01-02-hours-estimation/article.html <http://ronjeffries.com/articles/2015-01-02-hours-estimation/article.html>

Nice.

FWIW every team I’ve been involved with who has estimated in hours has, when the historical data was available, discovered that counting stories would have been as accurate, or in several cases would have been accurate.

Every. Single. Time.

If anybody is doing hour estimates, and has the historical data to check, I’d encourage them to have a look. And then ponder whether it’s really worth the effort involved.

Me — I just count stories (well
 throughput of stories really) coz my brain is tiny and math is hard


Acceptance test counts is not something I’ve tried. Added to the list of things to try. Thanks ;)

Cheers,

Adrian

[George Dinwiddie [e-mail] [SCRUMDEVELOPMENT]]

Post by Adrian Howard ***@quietstars.com [SCRUMDEVELOPMENT]

Post by Ron Jeffries ***@acm.org [SCRUMDEVELOPMENT]
http://ronjeffries.com/articles/2015-01-02-hours-estimation/article.html

Nice.
FWIW every team I’ve been involved with who has estimated in hours has,
when the historical data was available, discovered that counting stories
would have been as accurate, or in several cases would have been accurate.
Every. Single. Time.

Bob Payne and I found similar results looking at story point estimates
vs story counts.
http://idiacomputing.com/pub/Agile2012-What%27s%20the%20Point%20Of%20Story%20Points.pdf

Post by Adrian Howard ***@quietstars.com [SCRUMDEVELOPMENT]
If anybody is doing hour estimates, and has the historical data to
check, I’d encourage them to have a look. And then ponder whether it’s
really worth the effort involved.
Me — I just count stories (well
 throughput of stories really) coz my
brain is tiny and math is hard

Acceptance test counts is not something I’ve tried. Added to the list of
things to try. Thanks ;)

It works a charm also for splitting stories. Typically I find a small
handful of scenarios make a decent story slice.
http://blog.gdinwiddie.com/2011/05/01/splitting-user-stories/

- George

[Christofer Jennings [e-mail] [SCRUMDEVELOPMENT]]

Oh My Goodness!!! I’ve been named!!!! :)
I’m honored. Truly.


Slight correction though. I don’t think I said I found it useful for new teams. I think I said I was against a team using it if it helped them. (I don’t mind really.)


I very much like the idea of getting stories down to less than 2 days to finish, and with 1 acceptance criteria (AC). Now I’m wondering what one of those ACs might be. For example, are either of these acceptable ACs?


1. A user in the User Manager role can change a user’s address.


2. When a user’s address is changed, the first “street” line is required.


The wording may be clunky, but typically I see stories being at the level of changing the address and ACs include both the above and then some.
And I’ve seen mentions of roles like above turn into discussion about what other roles can do. That is, some developers get very finicky. So then do you ad more ACs or just leave it to the discussion?



 Tell us what you think, Ron!


:)
- Chris

Post by Ron Jeffries ***@acm.org [SCRUMDEVELOPMENT]
http://ronjeffries.com/articles/2015-01-02-hours-estimation/article.html <http://ronjeffries.com/articles/2015-01-02-hours-estimation/article.html>
Ron Jeffries
www.XProgramming.com <http://www.xprogramming.com/>
I'm not bad, I'm just drawn that way. -- Jessica Rabbit

[Ron Jeffries [e-mail] [SCRUMDEVELOPMENT]]

Hi Christofer,

Post by Christofer Jennings ***@gmail.com [SCRUMDEVELOPMENT]
I very much like the idea of getting stories down to less than 2 days to finish, and with 1 acceptance criteria (AC). Now I’m wondering what one of those ACs might be. For example, are either of these acceptable ACs?
1. A user in the User Manager role can change a user’s address.
2. When a user’s address is changed, the first “street” line is required.
The wording may be clunky, but typically I see stories being at the level of changing the address and ACs include both the above and then some.

They might be, if the story can be done in a couple of days. Otherwise what about:

Anyone can change the address, shown by entering “address” into a single field form;
Add fields to the form, Name, Address1, Address2, etc
Allow for entry of postal code, supply city / state if done;
Make some field required;
Implement some way of defining what’s required;
Add a required format to one field, perhaps postal code;
Add more required formats;
Make the form pretty;
Limit access to the form to one person, Joe Boss;
Limit access to everyone with Status = Boss: only specified people have the status;
Programmers can assign the status to anyone using code;
Make a page to assign status: build incrementally as above, field by field, person by person;
People have to have Status = SuperBoss to assign status: build up status as above;

 and so on 


Every one of these items actually has to be done for the big story to be done. Every one displays a small increment of functionality that the Product Owner can understand. These slices are almost certainly small enough to do in a few hours and I’d think that the worst team in history could do one of them in two days. If not, get in touch and I’ll come train them. :)

Post by Christofer Jennings ***@gmail.com [SCRUMDEVELOPMENT]
And I’ve seen mentions of roles like above turn into discussion about what other roles can do. That is, some developers get very finicky. So then do you ad more ACs or just leave it to the discussion?

If we don’t test it, PO doesn’t know if it works. If PO doesn’t know if it works, how can she accept the feature?

If we don’t automate the tests, PO doesn’t know if it works tomorrow. If PO doesn’t know if it works tomorrow, what does her acceptance actually mean?

Ron Jeffries
www.XProgramming.com
Before you contradict an old man, my fair friend, you should endeavor to understand him. - George Santayana

[[e-mail] [SCRUMDEVELOPMENT]]

Ron,

Interesting article. But still wonder how to do this:

Monitoring Sprint Progress
At any point in time in a Sprint, the total work remaining in the Sprint Backlog can be summed. The Development Team tracks this total work remaining at least for every Daily Scrum to project the likelihood of achieving the Sprint Goal. By tracking the remaining work throughout the Sprint, the Development Team can manage its progress. (c) Scrum Guide (July, 2013)

without estimating tasks in hours. Any ideas?

[Ron Jeffries [e-mail] [SCRUMDEVELOPMENT]]

Hennadii,

Post by ***@gmail.com [SCRUMDEVELOPMENT]
Monitoring Sprint Progress
At any point in time in a Sprint, the total work remaining in the Sprint Backlog can be summed. The Development Team tracks this total work remaining at least for every Daily Scrum to project the likelihood of achieving the Sprint Goal. By tracking the remaining work throughout the Sprint, the Development Team can manage its progress. (c) Scrum Guide (July, 2013)
without estimating tasks in hours. Any ideas?

Here are two:

Count the stories, measure the cycle time.
Pay less attention to what some Scrum guy said, and more to what works for you.

:)

Ron Jeffries
www.XProgramming.com
Everything that needs to be said has already been said.
But since no one was listening, everything must be said again. -- Andre Gide

[Markus Gaertner [e-mail] [SCRUMDEVELOPMENT]]

Here's a third: count the tasks rather than the stories that are left to
do. You don't need to estimate them. Has worked for me in the past.

Best
Markus

Scaling Agile as if you meant it: http://www.scaledprinciples.org
--
Dipl.-Inform. Markus Gaertner
Author of ATDD by Example - A Practical Guide to Acceptance Test-Driven
Development

http://www.shino.de/blog
http://www.mgaertne.de
http://www.it-agile.de

Post by Markus Gärtner ***@gmail.com [SCRUMDEVELOPMENT]
Hennadii,
Monitoring Sprint Progress
At any point in time in a Sprint, the total work remaining in the Sprint
Backlog can be summed. The Development Team tracks this total work
remaining at least for every Daily Scrum to project the likelihood of
achieving the Sprint Goal. By tracking the remaining work throughout the
Sprint, the Development Team can manage its progress. (c) Scrum Guide
(July, 2013)
without estimating tasks in hours. Any ideas?
1. Count the stories, measure the cycle time.
2. Pay less attention to what some Scrum guy said, and more to what
works for you.
:)
Ron Jeffries
www.XProgramming.com
Everything that needs to be said has already been said.
But since no one was listening, everything must be said again. -- Andre Gide

[George Dinwiddie [e-mail] [SCRUMDEVELOPMENT]]

I've done quite well burning down stories rather than tasks. It promotes
swarming over stories to get them done.

- George

Post by Markus Gaertner ***@gmail.com [SCRUMDEVELOPMENT]
Here's a third: count the tasks rather than the stories that are left to
do. You don't need to estimate them. Has worked for me in the past.
Best
Markus
Scaling Agile as if you meant it: http://www.scaledprinciples.org
--
Dipl.-Inform. Markus Gaertner
Author of ATDD by Example - A Practical Guide to Acceptance Test-Driven
Development
http://www.shino.de/blog
http://www.mgaertne.de
http://www.it-agile.de
Hennadii,

Post by ***@gmail.com [SCRUMDEVELOPMENT]
Monitoring Sprint Progress
At any point in time in a Sprint, the total work remaining in the
Sprint Backlog can be summed. The Development Team tracks this
total work remaining at least for every Daily Scrum to project the
likelihood of achieving the Sprint Goal. By tracking the remaining
work throughout the Sprint, the Development Team can manage its
progress. (c) Scrum Guide (July, 2013)
without estimating tasks in hours. Any ideas?

1. Count the stories, measure the cycle time.
2. Pay less attention to what some Scrum guy said, and more to what
works for you.
:)
Ron Jeffries
www.XProgramming.com <http://www.XProgramming.com>
Everything that needs to be said has already been said.
But since no one was listening, everything must be said again. -- Andre Gide

[Cass Dalton [e-mail] [SCRUMDEVELOPMENT]]

All of these ideas essentially revolve around a unit conversion from hours
to something that is a container of hours (stories, tasks, points, etc)
that *on average* represents a constant number of hours. Do you really
need to know exactly how many hours a particular story will take? No. You
need to know things like "When can we release feature X" or, in my case,
"will we be able to meet all the stated requirements in the current budget
and schedule". Story 1 can be 6 hours and story 2 can be 32 hours, as long
as a batch of stories (e.g. a sprint) has the same average story size as
the next batch or the previous batch.


It's similar to the difference between classical physics and quantum
mechanics. To be completely precise, we use quantum mechanics. But for
every day use, not only is classical physics good enough for our goals, but
we don't have the measurement accuracy to work in the quantum domain.
Well, if you have 20 stories that are about 2-3 days long on average, you
can come up with a "good enough" approximation of that time in hours that
will be within the estimation error of even the best software estimator.


-Cass

Post by Markus Gaertner ***@gmail.com [SCRUMDEVELOPMENT]
Here's a third: count the tasks rather than the stories that are left to
do. You don't need to estimate them. Has worked for me in the past.
Best
Markus
Scaling Agile as if you meant it: http://www.scaledprinciples.org
--
Dipl.-Inform. Markus Gaertner
Author of ATDD by Example - A Practical Guide to Acceptance Test-Driven
Development
http://www.shino.de/blog
http://www.mgaertne.de
http://www.it-agile.de

Post by Markus Gärtner ***@gmail.com [SCRUMDEVELOPMENT]
Hennadii,
Monitoring Sprint Progress
At any point in time in a Sprint, the total work remaining in the Sprint
Backlog can be summed. The Development Team tracks this total work
remaining at least for every Daily Scrum to project the likelihood of
achieving the Sprint Goal. By tracking the remaining work throughout the
Sprint, the Development Team can manage its progress. (c) Scrum Guide
(July, 2013)
without estimating tasks in hours. Any ideas?
1. Count the stories, measure the cycle time.
2. Pay less attention to what some Scrum guy said, and more to what
works for you.
:)
Ron Jeffries
www.XProgramming.com
Everything that needs to be said has already been said.
But since no one was listening, everything must be said again. -- Andre Gide

[George Dinwiddie [e-mail] [SCRUMDEVELOPMENT]]

Cass,

Post by Cass Dalton ***@gmail.com [SCRUMDEVELOPMENT]
All of these ideas essentially revolve around a unit conversion from
hours to something that is a container of hours (stories, tasks, points,
etc) that /on average/ represents a constant number of hours. Do you
really need to know exactly how many hours a particular story will
take? No. You need to know things like "When can we release feature X"
or, in my case, "will we be able to meet all the stated requirements in
the current budget and schedule". Story 1 can be 6 hours and story 2
can be 32 hours, as long as a batch of stories (e.g. a sprint) has the
same average story size as the next batch or the previous batch.

I respectfully disagree. When you burn down stories as they're
completed, rather than hours, you're tracking useful output rather than
effort. It no longer has anything to do with conversion to hours.

- George

[Cass Dalton [e-mail] [SCRUMDEVELOPMENT]]

I was speaking directly to the question of "how do I track status and
progress if I don't estimate hours". I was not speaking to the equivalence
of tracking hours to tracking stories. That's a subtle difference that I
guess was lost in my post. I completely agree that tracking anything other
than value is waste. I was just suggesting that any goal you need to
achieve by counting hours you can achieve by counting stories if you
understand (and create) the equivalence relationship that keeps the math
effectively the same.


-Cass

Post by George Dinwiddie ***@idiacomputing.com [SCRUMDEVELOPMENT]
Cass,

Post by Cass Dalton ***@gmail.com [SCRUMDEVELOPMENT]
All of these ideas essentially revolve around a unit conversion from
hours to something that is a container of hours (stories, tasks, points,
etc) that /on average/ represents a constant number of hours. Do you
really need to know exactly how many hours a particular story will
take? No. You need to know things like "When can we release feature X"
or, in my case, "will we be able to meet all the stated requirements in
the current budget and schedule". Story 1 can be 6 hours and story 2
can be 32 hours, as long as a batch of stories (e.g. a sprint) has the
same average story size as the next batch or the previous batch.

I respectfully disagree. When you burn down stories as they're
completed, rather than hours, you're tracking useful output rather than
effort. It no longer has anything to do with conversion to hours.
- George
--
----------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------

[Charles Bradley - Professional Scrum Trainer and Coach [e-mail] [SCRUMDEVELOPMENT]]

Counting Tasks is also my new favorite option for Shu Shu teams.  Of course, to work well, the tasks need to be small enough to show enough information for burndown/progress monitoring purposes.  I usually suggest "right sizing" all tasks to 1 day or less when executing this technique.
More here in Tips 2 and 3:ScrumCrazy - Sprint Tasking Tips

|   |
|   | |   |   |   |   |   |
| ScrumCrazy - Sprint Tasking TipsScrum Training Scrum Coaching Technical Coaching Quick Advice/Assessment Details of Coaching and Consulting services Contact Us |
| |
| View on www.scrumcrazy.com | Preview by Yahoo |
| |
|   |

 -------
Charles Bradley
Professional Scrum Trainer
Scrum Coach-in-Chief
http://ScrumCrazy.com


From: "Markus Gaertner ***@gmail.com [SCRUMDEVELOPMENT]" <***@yahoogroups.com>
To: "***@yahoogroups.com" <***@yahoogroups.com>
Sent: Monday, January 5, 2015 12:01 PM
Subject: Re: [SCRUMDEVELOPMENT] Hours Estimation?

#yiv0303743957 #yiv0303743957 -- #yiv0303743957 .yiv0303743957ygrp-photo-title{clear:both;font-size:smaller;height:15px;overflow:hidden;text-align:center;width:75px;}#yiv0303743957 div.yiv0303743957ygrp-photo{background-position:center;background-repeat:no-repeat;background-color:white;border:1px solid black;height:62px;width:62px;}#yiv0303743957 div.yiv0303743957photo-title a, #yiv0303743957 div.yiv0303743957photo-title a:active, #yiv0303743957 div.yiv0303743957photo-title a:hover, #yiv0303743957 div.yiv0303743957photo-title a:visited {text-decoration:none;}#yiv0303743957 div.yiv0303743957attach-table div.yiv0303743957attach-row {clear:both;}#yiv0303743957 div.yiv0303743957attach-table div.yiv0303743957attach-row div {float:left;}#yiv0303743957 p {clear:both;padding:15px 0 3px 0;overflow:hidden;}#yiv0303743957 div.yiv0303743957ygrp-file {width:30px;}#yiv0303743957 div.yiv0303743957attach-table div.yiv0303743957attach-row div div a {text-decoration:none;}#yiv0303743957 div.yiv0303743957attach-table div.yiv0303743957attach-row div div span {font-weight:normal;}#yiv0303743957 div.yiv0303743957ygrp-file-title {font-weight:bold;}#yiv0303743957 #yiv0303743957 #yiv0303743957 #yiv0303743957 --#yiv0303743957ygrp-mkp {border:1px solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv0303743957 #yiv0303743957ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv0303743957 #yiv0303743957ygrp-mkp #yiv0303743957hd {color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 0;}#yiv0303743957 #yiv0303743957ygrp-mkp #yiv0303743957ads {margin-bottom:10px;}#yiv0303743957 #yiv0303743957ygrp-mkp .yiv0303743957ad {padding:0 0;}#yiv0303743957 #yiv0303743957ygrp-mkp .yiv0303743957ad p {margin:0;}#yiv0303743957 #yiv0303743957ygrp-mkp .yiv0303743957ad a {color:#0000ff;text-decoration:none;}#yiv0303743957

Here's a third: count the tasks rather than the stories that are left to do. You don't need to estimate them. Has worked for me in the past.
BestMarkus
Scaling Agile as if you meant it: http://www.scaledprinciples.org--Dipl.-Inform. Markus Gaertner
Author of ATDD by Example - A Practical Guide to Acceptance Test-Driven Development
http://www.shino.de/blog
http://www.mgaertne.de
http://www.it-agile.de
Twitter: @mgaertne
On Mon, Jan 5, 2015 at 8:00 PM, Ron Jeffries ***@acm.org [SCRUMDEVELOPMENT] <***@yahoogroups.com> wrote:



Hennadii,

On Jan 4, 2015, at 11:48 AM, ***@gmail.com [SCRUMDEVELOPMENT] <***@yahoogroups.com> wrote:
Interesting article. But still wonder how to do this:

Monitoring Sprint Progress
At any point in time in a Sprint, the total work remaining in the Sprint Backlog can be summed. The Development Team tracks this total work remaining at least for every Daily Scrum to project the likelihood of achieving the Sprint Goal. By tracking the remaining work throughout the Sprint, the Development Team can manage its progress. (c) Scrum Guide (July, 2013)

without estimating tasks in hours. Any ideas?

Here are two:

- Count the stories, measure the cycle time.
- Pay less attention to what some Scrum guy said, and more to what works for you.

:)
Ron Jeffrieswww.XProgramming.comEverything that needs to be said has already been said.But since no one was listening, everything must be said again. -- Andre Gide

[Cass Dalton [e-mail] [SCRUMDEVELOPMENT]]

Post by Markus Gärtner ***@gmail.com [SCRUMDEVELOPMENT]
Hennadii,
Monitoring Sprint Progress
At any point in time in a Sprint, the total work remaining in the Sprint
Backlog can be summed. The Development Team tracks this total work
remaining at least for every Daily Scrum to project the likelihood of
achieving the Sprint Goal. By tracking the remaining work throughout the
Sprint, the Development Team can manage its progress. (c) Scrum Guide
(July, 2013)
without estimating tasks in hours. Any ideas?
1. Count the stories, measure the cycle time.
2. Pay less attention to what some Scrum guy said, and more to what
works for you.
3. Pay less attention to what management is asking you for and more to

what you really need to know.

Post by Markus Gärtner ***@gmail.com [SCRUMDEVELOPMENT]
:)
Ron Jeffries
www.XProgramming.com
Everything that needs to be said has already been said.
But since no one was listening, everything must be said again. -- Andre Gide

[[e-mail] [SCRUMDEVELOPMENT]]

Ron,

Yep, really like the second option. Should have stopped paying attention to what 'some Scrum guy' say long ago :D

[Michael James [e-mail] [SCRUMDEVELOPMENT]]

Post by ***@gmail.com [SCRUMDEVELOPMENT]
Yep, really like the second option. Should have stopped paying attention to what 'some Scrum guy' say long ago :D

The part we all seem to agree with some Scrum guy about is that it’s useful for the whole team to be able to visualize all the work, ideally at a glance. (Ideally there’s no “my work” or “your work” on a collaborative team.) A physical taskboard can help with this, and it’s also better to focus on PBIs/stories than tasks.

—mj
(Michael)

[Ron Jeffries [e-mail] [SCRUMDEVELOPMENT]]

+1;

Post by Michael James ***@gmail.com [SCRUMDEVELOPMENT]
The part we all seem to agree with some Scrum guy about is that it’s useful for the whole team to be able to visualize all the work, ideally at a glance. (Ideally there’s no “my work” or “your work” on a collaborative team.) A physical taskboard can help with this, and it’s also better to focus on PBIs/stories than tasks.

Ron Jeffries
www.XProgramming.com <http://www.xprogramming.com/>
If it is more than you need, it is waste. -- Andy Seidl

[Cass Dalton [e-mail] [SCRUMDEVELOPMENT]]

We story count and we also can predict the future to within the same error
as any form of hour estimation you try. It's just that the hour estimation

has a higher precision, not higher accuracy so it LOOKS like you have
better prediction power.


In my experience, one of the benefits of a constant average story size is
the increase in prediction accuracy (again, not precision) over time based
estimation. As you move forward completing stories, you will have actual
records of how many stories a chunk of work (Epic, feature, etc) took and
you can continue to refine future estimates in units of 2-3 day stories (or
whatever your chosen size). If you want long term estimations with a
granularity of hours, you're either fooling yourself about how good ANYONE
is at estimating software development, or you're a manager (the two are
often synonymous).


So anywhere where you want an estimate in hours, try quantizing that
estimate to 2-3 day units and start calling that unit a story. The math
doesn't change, but your appreciation of how much you don't know increases.


-Cass

Post by ***@gmail.com [SCRUMDEVELOPMENT]
Ron,
Monitoring Sprint Progress
At any point in time in a Sprint, the total work remaining in the Sprint
Backlog can be summed. The Development Team tracks this total work
remaining at least for every Daily Scrum to project the likelihood of
achieving the Sprint Goal. By tracking the remaining work throughout the
Sprint, the Development Team can manage its progress. (c) Scrum Guide
(July, 2013)
without estimating tasks in hours. Any ideas?

[Ron Jeffries [e-mail] [SCRUMDEVELOPMENT]]

Hennadii,

Post by ***@gmail.com [SCRUMDEVELOPMENT]
Monitoring Sprint Progress
At any point in time in a Sprint, the total work remaining in the Sprint Backlog can be summed. The Development Team tracks this total work remaining at least for every Daily Scrum to project the likelihood of achieving the Sprint Goal. By tracking the remaining work throughout the Sprint, the Development Team can manage its progress. (c) Scrum Guide (July, 2013)
without estimating tasks in hours. Any ideas?

Yes, but first I’d like to challenge you to come up with two or three ways of knowing how much remains to be done without hours estimation.

Ron Jeffries
www.XProgramming.com
It's true hard work never killed anybody, but I figure, why take the chance?
-- Ronald Reagan

[Bob Paige [e-mail] [SCRUMDEVELOPMENT]]

I'm in a similar situation, where management's concern is "will we get
everything done by the specified date."


I monitor these discussions with envy as we move further and further away
from Agile.


"Alas Agile, we hardly knew ye."

Post by Markus Gärtner ***@gmail.com [SCRUMDEVELOPMENT]
Hennadii,
Monitoring Sprint Progress
At any point in time in a Sprint, the total work remaining in the Sprint
Backlog can be summed. The Development Team tracks this total work
remaining at least for every Daily Scrum to project the likelihood of
achieving the Sprint Goal. By tracking the remaining work throughout the
Sprint, the Development Team can manage its progress. (c) Scrum Guide
(July, 2013)
without estimating tasks in hours. Any ideas?
Yes, but first I’d like to challenge you to come up with two or three ways
of knowing how much remains to be done without hours estimation.
Ron Jeffries
www.XProgramming.com
It's true hard work never killed anybody, but I figure, why take the chance?
-- Ronald Reagan

[Kurt Häusler [e-mail] [SCRUMDEVELOPMENT]]

At least management left the third side of the triangle open, plenty of room for agility there.

On 06.01.2015 17:18:31, Bob Paige ***@gmail.com [SCRUMDEVELOPMENT] <***@yahoogroups.com> wrote:
 
I'm in a similar situation, where management's concern is "will we get everything done by the specified date."


I monitor these discussions with envy as we move further and further away from Agile.

"Alas Agile, we hardly knew ye."

[Charles Bradley - Professional Scrum Trainer and Coach [e-mail] [SCRUMDEVELOPMENT]]

Kurt, 
It appears to me the only side of the triangle open is "resources' or 'cost'.... but that leads to a conflict with Brook's law.
While I think there *might* be room for agility there, it's not *much* room.
So, generally speaking, even fixing scope and date is a giant trap/fallacy/fool's errand IMO.  (especially over a few months time period with complex(Cynefin) work)
 -------
Charles Bradley
Professional Scrum Trainer
Scrum Coach-in-Chief
http://ScrumCrazy.com


From: "Kurt HÀusler ***@gmail.com [SCRUMDEVELOPMENT]" <***@yahoogroups.com>
To: "Bob Paige ***@gmail.com [SCRUMDEVELOPMENT]" <***@yahoogroups.com>
Sent: Tuesday, January 6, 2015 9:33 AM
Subject: Re: [SCRUMDEVELOPMENT] Hours Estimation?

#yiv3903740844 #yiv3903740844 -- .yiv3903740844ygrp-photo-title{clear:both;font-size:smaller;height:15px;overflow:hidden;text-align:center;width:75px;}#yiv3903740844 div.yiv3903740844ygrp-photo{background-position:center;background-repeat:no-repeat;background-color:white;border:1px solid black;height:62px;width:62px;}#yiv3903740844 div.yiv3903740844photo-title a, #yiv3903740844 div.yiv3903740844photo-title a:active, #yiv3903740844 div.yiv3903740844photo-title a:hover, #yiv3903740844 div.yiv3903740844photo-title a:visited {text-decoration:none;}#yiv3903740844 div.yiv3903740844attach-table div.yiv3903740844attach-row {clear:both;}#yiv3903740844 div.yiv3903740844attach-table div.yiv3903740844attach-row div {float:left;}#yiv3903740844 p {clear:both;padding:15px 0 3px 0;overflow:hidden;}#yiv3903740844 div.yiv3903740844ygrp-file {width:30px;}#yiv3903740844 div.yiv3903740844attach-table div.yiv3903740844attach-row div div a {text-decoration:none;}#yiv3903740844 div.yiv3903740844attach-table div.yiv3903740844attach-row div div span {font-weight:normal;}#yiv3903740844 div.yiv3903740844ygrp-file-title {font-weight:bold;}#yiv3903740844 #yiv3903740844 #yiv3903740844 -- #yiv3903740844ygrp-mkp {border:1px solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv3903740844 #yiv3903740844ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv3903740844 #yiv3903740844ygrp-mkp #yiv3903740844hd {color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 0;}#yiv3903740844 #yiv3903740844ygrp-mkp #yiv3903740844ads {margin-bottom:10px;}#yiv3903740844 #yiv3903740844ygrp-mkp .yiv3903740844ad {padding:0 0;}#yiv3903740844 #yiv3903740844ygrp-mkp .yiv3903740844ad p {margin:0;}#yiv3903740844 #yiv3903740844ygrp-mkp .yiv3903740844ad a {color:#0000ff;text-decoration:none;}#yiv3903740844

At least management left the third side of the triangle open, plenty of room for agility there.

On 06.01.2015 17:18:31, Bob Paige ***@gmail.com [SCRUMDEVELOPMENT] <***@yahoogroups.com> wrote:  I'm in a similar situation, where management's concern is "will we get everything done by the specified date."

I monitor these discussions with envy as we move further and further away from Agile.
"Alas Agile, we hardly knew ye."

[Cass Dalton [e-mail] [SCRUMDEVELOPMENT]]

I work in a traditional culture working for an incredibly traditional
customer in a notoriously traditional regulatory environment (defense
contracting). I have constant pressure to provide traditional style
metrics for progress. The most success I have had is working with these
stakeholders to find out what they need from the statistics and do my best
to generate the metrics they are used to from the agile metrics I have
(i.e. computing EVM's SPI and CPI from story burn down and projected story
count to implement required functionality. I try to minimize how much
silly metrics drive the development process. When people complain that the
metrics don't always show consistent progress, I try to get them to realize
that their old metrics weren't really any more accurate (in fact, the agile
metrics are probably more accurate than the old metrics), they just hid the
real situation well.


In short, if you can give program managers, business administrators, or
executives the warm fuzzies that they used to get from their old metrics,
they will be less inclined to micro-manage the details. And if you can
show positive results, they will start to trust you even if they don't
really understand what you're doing.

Post by Bob Paige ***@gmail.com [SCRUMDEVELOPMENT]
I'm in a similar situation, where management's concern is "will we get
everything done by the specified date."
I monitor these discussions with envy as we move further and further away
from Agile.
"Alas Agile, we hardly knew ye."

Post by Markus Gärtner ***@gmail.com [SCRUMDEVELOPMENT]
Hennadii,
Monitoring Sprint Progress
At any point in time in a Sprint, the total work remaining in the Sprint
Backlog can be summed. The Development Team tracks this total work
remaining at least for every Daily Scrum to project the likelihood of
achieving the Sprint Goal. By tracking the remaining work throughout the
Sprint, the Development Team can manage its progress. (c) Scrum Guide
(July, 2013)
without estimating tasks in hours. Any ideas?
Yes, but first I’d like to challenge you to come up with two or three
ways of knowing how much remains to be done without hours estimation.
Ron Jeffries
www.XProgramming.com
It's true hard work never killed anybody, but I figure, why take the
chance?
-- Ronald Reagan

[[e-mail] [SCRUMDEVELOPMENT]]

Ron,

There have been many more that just 2 or 3 ideas on the list (btw, appreciate everyone speaking up on the issue!) so I don't feel it is fair for me to come up with ideas after that :)

[George Dinwiddie [e-mail] [SCRUMDEVELOPMENT]]

Christofer,

Post by Christofer Jennings ***@gmail.com [SCRUMDEVELOPMENT]
Hi All,
Do you do hours estimation for tasks in stories?

I prefer not to track at the task level, as it seems to dilute the
effort to getting stories done. I've seen this happen with many teams.
They'll burn down hours and things look great, but at the end of the
sprint a number of stories are "not quite done."

Post by Christofer Jennings ***@gmail.com [SCRUMDEVELOPMENT]
I don’t mean to imply estimating hours is a bad thing all the time. I
just think it’s often not worth the effort. That is, it’s often
wasteful.
Simply looking at a well run task board makes the hours burndown seem
unnecessary. Knowing the velocity of the team, the size of the
stories, the time remaining, and spread of task tickets on the board
gives me an immediate gestalt of progress. The team sees the board
and can tell me if they think “all that stuff” will be done by sprint
end, or if they need to add/remove scope. None of that requires
hours, imho.
I’ve come to see hours estimation as optional. The Agile Manifesto
principle "Simplicity--the art of maximizing the amount of work not
done--is essential” tells me that if it’s not essential then it’s
best not done. (aka Lean muda)

Inspect and adapt. There's not much that isn't optional. Experiment
mindfully and see how things work for you.

Post by Christofer Jennings ***@gmail.com [SCRUMDEVELOPMENT]
My experience is that doing the hours estimation is useful for teams
to get good at estimating how much work there is. It’s a kind of
sanity check during planning to see that the dev team is not under or
over capacity. It also gives a nice way to have a burndown chart. But
it brings up other things that work against the team, even in early
formation of the team. For example, hours are often specific to
individuals and their background so estimating hours leads to
assigning tasks. When a team is estimating, developers haggle about
the hours. The haggling can be productive but is also emotionally
draining because people may feel like heroes and peasants. Or people
may simply say, “well, he knows it takes 2 hours and I don’t, so,
whatever”. Then, since the hours are person-specific, the tasks need
to be assigned. Etc.

You can burndown story points, too. I find that more useful.

Post by Christofer Jennings ***@gmail.com [SCRUMDEVELOPMENT]
So I’m wondering. How common is it to just not use hours estimation?

Quite common in my experience. In my coaching experience, it's the rare
team that estimates task hours. It's even rarer that they really
re-estimate daily rather than subtracting the number of hours they
worked on a task.

- George

[Christofer Jennings [e-mail] [SCRUMDEVELOPMENT]]

Hi All,


Thanks to everyone who responded!
I may no reply back to each one so I just want to be sure you know my appreciation! :)


- Chris

Post by Christofer Jennings ***@gmail.com [SCRUMDEVELOPMENT]
Hi All,
Do you do hours estimation for tasks in stories?
I don’t mean to imply estimating hours is a bad thing all the time. I just think it’s often not worth the effort. That is, it’s often wasteful.
Simply looking at a well run task board makes the hours burndown seem unnecessary. Knowing the velocity of the team, the size of the stories, the time remaining, and spread of task tickets on the board gives me an immediate gestalt of progress. The team sees the board and can tell me if they think “all that stuff” will be done by sprint end, or if they need to add/remove scope. None of that requires hours, imho.
I’ve come to see hours estimation as optional. The Agile Manifesto principle "Simplicity--the art of maximizing the amount of work not done--is essential” tells me that if it’s not essential then it’s best not done. (aka Lean muda)
My experience is that doing the hours estimation is useful for teams to get good at estimating how much work there is. It’s a kind of sanity check during planning to see that the dev team is not under or over capacity. It also gives a nice way to have a burndown chart. But it brings up other things that work against the team, even in early formation of the team. For example, hours are often specific to individuals and their background so estimating hours leads to assigning tasks. When a team is estimating, developers haggle about the hours. The haggling can be productive but is also emotionally draining because people may feel like heroes and peasants. Or people may simply say, “well, he knows it takes 2 hours and I don’t, so, whatever”. Then, since the hours are person-specific, the tasks need to be assigned. Etc.
So I’m wondering. How common is it to just not use hours estimation?
Thanks!
-Chris

[Charles Bradley - Professional Scrum Trainer and Coach [e-mail] [SCRUMDEVELOPMENT]]

Agree with Tobias and Ron's views on this thread, with a couple of things I'd like to add:

- As others have said, if you're estimating a lot of PBI's (handful or more per sprint should be your minimum anyways), the estimate differences will work themselves out over time.  On the rare cases they don't don't, anomalies can be handled in retros and improved going forward.  No need to re-estimate PBI's.  Others have hinted at this by asking what value there is in Re-estimating -- this is so that they can help the original poster understand that their are very likely better practices for handling their root cause need.  So, until the root cause need is discovered and dealt with, the Original Poster will probably not learn what they need to learn.

- (summarizing/paraphrasing here) The micro stories and counting stories concepts that Ron and others have advocated for years are great.  I tend to work with Shu Shu teams (and organizations not willing to adequately invest in Agile) mostly, and so I've never actually seen this practice fully implemented in the field, but I believe strongly in the fundamentals and think it would be awesome.  I've seen the benefits in cases where stories are small.. or get small.. on a team -- so I've personally witnessed part of the benefit.  I always encourage small stories, but I'm often not at a client long enough to have that "transition to Agile - micro stories practice" item pop to the top of my "transition" backlog.  Ron and others might implement this particular practice earlier in their gigs -- I generally choose not to for reasons that are beyond an email conversation.  I focus on other things like Scrum principles, etc.  This is not to say either way is best.  I have a TON of respect for both Ron and Tobias and the others on this list.  (Also, Cass -- great posts!)

- One thing I haven't seen mentioned heavily here is that there is an inherent complexity in all software development, so trying to get estimates to be totally accurate is a complete fool's errand. Further, it completely inhibits and helps teams to violate the Agile Manifesto value statements (primarily responding to change over following a plan). 

- The above fool's errand leads us to the king of all dysfunctions in software development... Schedule/Scope/Cost, and all of the bad thinking that goes along with that. SSC might work fine in other domains, but it's a dead model in software dev.  Until people realize that model is dead in software, they will continue to fall back into PMI/waterfall planning traps.

 -------
Charles Bradley
Professional Scrum Trainer
Scrum Coach-in-Chief
http://ScrumCrazy.com


From: "Ron Jeffries ***@acm.org [SCRUMDEVELOPMENT]" <***@yahoogroups.com>
To: ***@yahoogroups.com
Sent: Wednesday, December 24, 2014 8:02 AM
Subject: Re: [SCRUMDEVELOPMENT] Re: Re-estimating PBIs

#yiv8186203026 #yiv8186203026 -- #yiv8186203026 .yiv8186203026ygrp-photo-title{clear:both;font-size:smaller;height:15px;overflow:hidden;text-align:center;width:75px;}#yiv8186203026 div.yiv8186203026ygrp-photo{background-position:center;background-repeat:no-repeat;background-color:white;border:1px solid black;height:62px;width:62px;}#yiv8186203026 div.yiv8186203026photo-title a, #yiv8186203026 div.yiv8186203026photo-title a:active, #yiv8186203026 div.yiv8186203026photo-title a:hover, #yiv8186203026 div.yiv8186203026photo-title a:visited {text-decoration:none;}#yiv8186203026 div.yiv8186203026attach-table div.yiv8186203026attach-row {clear:both;}#yiv8186203026 div.yiv8186203026attach-table div.yiv8186203026attach-row div {float:left;}#yiv8186203026 p {clear:both;padding:15px 0 3px 0;overflow:hidden;}#yiv8186203026 div.yiv8186203026ygrp-file {width:30px;}#yiv8186203026 div.yiv8186203026attach-table div.yiv8186203026attach-row div div a {text-decoration:none;}#yiv8186203026 div.yiv8186203026attach-table div.yiv8186203026attach-row div div span {font-weight:normal;}#yiv8186203026 div.yiv8186203026ygrp-file-title {font-weight:bold;}#yiv8186203026 #yiv8186203026

I stand corrected. 

Post by Ron Jeffries ***@acm.org [SCRUMDEVELOPMENT]

It wasn't intended as sarcasm. It was intended as truth-speaking. 

I’d expect truth-speaking to involve speaking truth.

Yes.

Estimating work once the work is done...will be 100% accurate
True.

you will prove that all the previous guesswork was wrong. 
True.

Telling people they are wrong is a very good way to keep them in their place, and maintain control. 
True.

Detention is also a good punishment
True.

—and beneficial to management
Dubiously true—it depends on how one measures "benefit".

as it keeps people at work longer. 
True.

The no-lunch part was non-serious suggestion. I guess that part could be interpreted as sarcasm. It was intended to highlight folly.


I sort of thought that was the point of the entire remark. I regret not understanding immediately.
Ron Jeffrieswww.ronjeffries.comSometimes you just have to stop holding on with both hands, both feet, and your tail, to get someplace better. Of course you might plummet to the earth and die, but probably not: you were made for this.

[Charles Bradley - Professional Scrum Trainer and Coach [e-mail] [SCRUMDEVELOPMENT]]

Responding to my own post.  Yeay!!  :-)

Post by Charles Bradley - Professional Scrum Trainer and Coach chuck-***@emailchuck.com [SCRUMDEVELOPMENT]
One thing I haven't seen mentioned heavily here is that there is an inherent complexity in all software development, so trying to get estimates to be totally accurate is a complete fool's errand. Further, it completely inhibits and helps teams to violate the Agile Manifesto value statements (primarily responding to change over following a plan)

Said another way, if we were making the same widget over and over and over again, getting to this level of estimate accuracy might actually be valuable.  But software is not an assembly line, and it is not manufacturing, which is why many of the "manufacturing" models/principles do NOT transfer will into software.  Let me just stop here before I decide to talk about the dangers of misunderstanding what "Lean" really is.  Another topic not well done over email.
-------
Charles Bradley
Professional Scrum Trainer
Scrum Coach-in-Chief
http://ScrumCrazy.com


From: "Charles Bradley - Professional Scrum Trainer and Coach chuck-***@emailchuck.com [SCRUMDEVELOPMENT]" <***@yahoogroups.com>
To: "***@yahoogroups.com" <***@yahoogroups.com>
Sent: Friday, January 2, 2015 12:15 PM
Subject: Re: [SCRUMDEVELOPMENT] Re: Re-estimating PBIs

#yiv5509344979 #yiv5509344979 -- #yiv5509344979 .yiv5509344979ygrp-photo-title{clear:both;font-size:smaller;height:15px;overflow:hidden;text-align:center;width:75px;}#yiv5509344979 div.yiv5509344979ygrp-photo{background-position:center;background-repeat:no-repeat;background-color:white;border:1px solid black;height:62px;width:62px;}#yiv5509344979 div.yiv5509344979photo-title a, #yiv5509344979 div.yiv5509344979photo-title a:active, #yiv5509344979 div.yiv5509344979photo-title a:hover, #yiv5509344979 div.yiv5509344979photo-title a:visited {text-decoration:none;}#yiv5509344979 div.yiv5509344979attach-table div.yiv5509344979attach-row {clear:both;}#yiv5509344979 div.yiv5509344979attach-table div.yiv5509344979attach-row div {float:left;}#yiv5509344979 p {clear:both;padding:15px 0 3px 0;overflow:hidden;}#yiv5509344979 div.yiv5509344979ygrp-file {width:30px;}#yiv5509344979 div.yiv5509344979attach-table div.yiv5509344979attach-row div div a {text-decoration:none;}#yiv5509344979 div.yiv5509344979attach-table div.yiv5509344979attach-row div div span {font-weight:normal;}#yiv5509344979 div.yiv5509344979ygrp-file-title {font-weight:bold;}#yiv5509344979 #yiv5509344979

Agree with Tobias and Ron's views on this thread, with a couple of things I'd like to add:

- As others have said, if you're estimating a lot of PBI's (handful or more per sprint should be your minimum anyways), the estimate differences will work themselves out over time.  On the rare cases they don't don't, anomalies can be handled in retros and improved going forward.  No need to re-estimate PBI's.  Others have hinted at this by asking what value there is in Re-estimating -- this is so that they can help the original poster understand that their are very likely better practices for handling their root cause need.  So, until the root cause need is discovered and dealt with, the Original Poster will probably not learn what they need to learn.

- (summarizing/paraphrasing here) The micro stories and counting stories concepts that Ron and others have advocated for years are great.  I tend to work with Shu Shu teams (and organizations not willing to adequately invest in Agile) mostly, and so I've never actually seen this practice fully implemented in the field, but I believe strongly in the fundamentals and think it would be awesome.  I've seen the benefits in cases where stories are small.. or get small.. on a team -- so I've personally witnessed part of the benefit.  I always encourage small stories, but I'm often not at a client long enough to have that "transition to Agile - micro stories practice" item pop to the top of my "transition" backlog.  Ron and others might implement this particular practice earlier in their gigs -- I generally choose not to for reasons that are beyond an email conversation.  I focus on other things like Scrum principles, etc.  This is not to say either way is best.  I have a TON of respect for both Ron and Tobias and the others on this list.  (Also, Cass -- great posts!)

- One thing I haven't seen mentioned heavily here is that there is an inherent complexity in all software development, so trying to get estimates to be totally accurate is a complete fool's errand. Further, it completely inhibits and helps teams to violate the Agile Manifesto value statements (primarily responding to change over following a plan). 

- The above fool's errand leads us to the king of all dysfunctions in software development... Schedule/Scope/Cost, and all of the bad thinking that goes along with that. SSC might work fine in other domains, but it's a dead model in software dev.  Until people realize that model is dead in software, they will continue to fall back into PMI/waterfall planning traps.

 -------
Charles Bradley
Professional Scrum Trainer
Scrum Coach-in-Chief
http://ScrumCrazy.com


From: "Ron Jeffries ***@acm.org [SCRUMDEVELOPMENT]" <***@yahoogroups.com>
To: ***@yahoogroups.com
Sent: Wednesday, December 24, 2014 8:02 AM
Subject: Re: [SCRUMDEVELOPMENT] Re: Re-estimating PBIs

#yiv5509344979 -- .yiv5509344979ygrp-photo-title{clear:both;font-size:smaller;height:15px;overflow:hidden;text-align:center;width:75px;}#yiv5509344979 div.yiv5509344979ygrp-photo{background-position:center;background-repeat:no-repeat;background-color:white;border:1px solid black;height:62px;width:62px;}#yiv5509344979 div.yiv5509344979photo-title a, #yiv5509344979 div.yiv5509344979photo-title a:active, #yiv5509344979 div.yiv5509344979photo-title a:hover, #yiv5509344979 div.yiv5509344979photo-title a:visited {text-decoration:none;}#yiv5509344979 div.yiv5509344979attach-table div.yiv5509344979attach-row {clear:both;}#yiv5509344979 div.yiv5509344979attach-table div.yiv5509344979attach-row div {float:left;}#yiv5509344979 p {clear:both;padding:15px 0 3px 0;overflow:hidden;}#yiv5509344979 div.yiv5509344979ygrp-file {width:30px;}#yiv5509344979 div.yiv5509344979attach-table div.yiv5509344979attach-row div div a {text-decoration:none;}#yiv5509344979 div.yiv5509344979attach-table div.yiv5509344979attach-row div div span {font-weight:normal;}#yiv5509344979 div.yiv5509344979ygrp-file-title {font-weight:bold;}#yiv5509344979

I stand corrected. 

Post by Charles Bradley - Professional Scrum Trainer and Coach chuck-***@emailchuck.com [SCRUMDEVELOPMENT]

It wasn't intended as sarcasm. It was intended as truth-speaking. 

I’d expect truth-speaking to involve speaking truth.

Yes.

Estimating work once the work is done...will be 100% accurate
True.

you will prove that all the previous guesswork was wrong. 
True.

Telling people they are wrong is a very good way to keep them in their place, and maintain control. 
True.

Detention is also a good punishment
True.

—and beneficial to management
Dubiously true—it depends on how one measures "benefit".

as it keeps people at work longer. 
True.

The no-lunch part was non-serious suggestion. I guess that part could be interpreted as sarcasm. It was intended to highlight folly.


I sort of thought that was the point of the entire remark. I regret not understanding immediately.
Ron Jeffrieswww.ronjeffries.comSometimes you just have to stop holding on with both hands, both feet, and your tail, to get someplace better. Of course you might plummet to the earth and die, but probably not: you were made for this.

[George Dinwiddie [e-mail] [SCRUMDEVELOPMENT]]

Charles,

On 1/2/15 2:15 PM, Charles Bradley - Professional Scrum Trainer and

(summarizing/paraphrasing here) The micro stories
<http://www.scrumcrazy.com/User+Story+Pattern+-+Micro+Stories> and
counting stories concepts that Ron and others have advocated for years
are great. I tend to work with Shu Shu teams (and organizations not
willing to adequately invest in Agile) mostly, and so I've never
actually seen this practice fully implemented in the field, but I
believe strongly in the fundamentals and think it would be awesome. I've
seen the benefits in cases where stories are small.. or get small.. on a
team -- so I've personally witnessed part of the benefit. I always
encourage small stories, but I'm often not at a client long enough to
have that "transition to Agile - micro stories practice" item pop to the
top of my "transition" backlog.

I no longer start with the suggestion of small stories. Instead, I start
with the suggestion of being so clear about what's in a story that you
can list the scenarios covered by it. Leaving the acceptance criteria
fuzzy and abstract leads to all sorts of problems.

Of course, once they list the scenarios, I suggest "why don't we treat
this scenario as the first story split, then these three as the next, ..."

Try it; I think you'll like it.

- George

[Charles Bradley - Professional Scrum Trainer and Coach [e-mail] [SCRUMDEVELOPMENT]]

Good point,George, and I thought to "shout out" that technique and you (because I know you advocate it highly) while I was drafting that email -- and then forgot to do so.
Yes, agreed, splitting via acceptance criteria/acceptance tests is very often a great way to split stories.  I also use your technique very often(let's call this one acc criteria a story, ok?).  Also dovetails nicely with Spec by Example.

Another shout out I forgot to mention is the idea of using "acceptance tests" as an estimating mechanism for PBI's and then using # of failing acceptance tests to create a burndown(but I think someone else on the thread mentioned this).  This is one of those other techniques that I think is awesome but have never seen in the field. (heard rumors though, would love to witness/try one day)
 -------
Charles Bradley
Professional Scrum Trainer
Scrum Coach-in-Chief
http://ScrumCrazy.com


From: "George Dinwiddie ***@idiacomputing.com [SCRUMDEVELOPMENT]" <***@yahoogroups.com>
To: ***@yahoogroups.com
Sent: Friday, January 2, 2015 1:07 PM
Subject: Re: [SCRUMDEVELOPMENT] Re: Re-estimating PBIs

Charles,

On 1/2/15 2:15 PM, Charles Bradley - Professional Scrum Trainer and

(summarizing/paraphrasing here) The micro stories
<http://www.scrumcrazy.com/User+Story+Pattern+-+Micro+Stories> and
counting stories concepts that Ron and others have advocated for years
are great.  I tend to work with Shu Shu teams (and organizations not
willing to adequately invest in Agile) mostly, and so I've never
actually seen this practice fully implemented in the field, but I
believe strongly in the fundamentals and think it would be awesome. I've
seen the benefits in cases where stories are small.. or get small.. on a
team -- so I've personally witnessed part of the benefit.  I always
encourage small stories, but I'm often not at a client long enough to
have that "transition to Agile - micro stories practice" item pop to the
top of my "transition" backlog.

I no longer start with the suggestion of small stories. Instead, I start
with the suggestion of being so clear about what's in a story that you
can list the scenarios covered by it. Leaving the acceptance criteria
fuzzy and abstract leads to all sorts of problems.

Of course, once they list the scenarios, I suggest "why don't we treat
this scenario as the first story split, then these three as the next, ..."

Try it; I think you'll like it.

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



------------------------------------
Posted by: George Dinwiddie <***@iDIAcomputing.com>


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

To Post a message, send it to:  ***@eGroups.com
To Unsubscribe, send a blank message to: SCRUMDEVELOPMENT-***@eGroups.com
------------------------------------

Yahoo Groups Links

[Tobias Mayer [e-mail] [SCRUMDEVELOPMENT]]

Estimating work once the work is done is great. You will be 100%
accurate—and more importantly you will prove that all the previous
guesswork was wrong. Telling people they are wrong is a very good way to
keep them in their place, and maintain control. So I say go for it. You may
also want to introduce a punishment system based on just how wrong they
were, say prohibiting a coffee break if a little bit wrong, and missing
lunch if they are more wrong. Detention is also a good punishment—and
beneficial to management, as it keeps people at work longer.

[Laurent Bossavit [e-mail] [SCRUMDEVELOPMENT]]

In addition to the excellent replies that others have provided, allow me to point out the obvious...

In Scrum, the team *decides* how to organize work, in order to meet objectives. "Asking" the team to do things a certain way smells of micromanagement.

Management sets objectives. The team owns the process.

My recommendation: revisit your agreements with the people who have been doing the asking. Do they understand that the team owns the process?

Cheers,
Laurent Bossavit

[Silvana Wasitova [e-mail] [SCRUMDEVELOPMENT]]

Ha ha... hilarious, Toby! :)


Sent from Samsung Mobile

-------- Original message --------
From: "***@tobymayer.com [SCRUMDEVELOPMENT]" <***@yahoogroups.com>
Date: 23/12/2014 16:56 (GMT+01:00)
To: ***@yahoogroups.com
Subject: [SCRUMDEVELOPMENT] Re: Re-estimating PBIs

Estimating work once the work is done is great. You will be 100% accurate—and more importantly you will prove that all the previous guesswork was wrong. Telling people they are wrong is a very good way to keep them in their place, and maintain control. So I say go for it. You may also want to introduce a punishment system based on just how wrong they were, say prohibiting a coffee break if a little bit wrong, and missing lunch if they are more wrong. Detention is also a good punishment—and beneficial to management, as it keeps people at work longer.

[Adam Sroka [e-mail] [SCRUMDEVELOPMENT]]

What benefit do you gain by spending energy proving something you already
know - that your estimates were guesses?

Post by ***@gmail.com [SCRUMDEVELOPMENT]
Hi,
My current team has been asked to re-estimate PBIs: at the end of the
sprint to make sure PBIs turned out to be of the size they had been
estimated initially, and at the beginning of the sprint for those PBIs that
has been carried over from previous sprints as not done.
Therefore, my question i: whether re-estimation of PBIs is considered to
be a good practice or bad, what pros and cons are intrinsic to this
approach.

['Quick, Alissa' [e-mail] [SCRUMDEVELOPMENT]]

We use hours with the lowest possible value being 1 hour. Long-term I would like to get away from hours estimation at a task level, but with new or maturing teams, I find it extremely valuable. For one, it helps ensure team members are not overcommitting themselves during a sprint cycle. For two, it helps ensure tasks are broken into reasonable chunks of work - which in turn allows for better status updates at daily stand-ups and sharing of tasks with team members. For three, it seems to help the team really think about the work needed...by putting an hour value on it, it ensures they've thought through the tasks enough before taking it on.


The information contained in this message may be privileged, confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify your representative immediately and delete this message from your computer. Thank you.