Re: Spike user stories
- --- In firstname.lastname@example.org, "aefager" <aefager@...> wrote:
> I just want to get a clarification here.What I have found that works best for the teams I work with, is sizing
> 1. You are a proponent of accurate estimation.
> 2. You are a proponent of Scrum.
> 3. You are a proponent of story points over hours.
> Does this mean that in a burndown chart, you would use story points,
> in place of hours? Do you still have burndowns, and are now doing
> them on story points, or did I misunderstand?
points at the story level withing the product backlog, and then
estimating hours for each task identified for each planned story
during sprint planning. This is also what Mike Cohn speaks about in
his "Agile Estimation and Planning" session. This way you are able to
have a Sprint Burndown in hours, reflecting work remaining for the
sprint, and Release Burndown or Product Burndown in Story Points.
- Hello Marco, thanks for sharing your thoughts. On Monday, August 21,
2006, at 9:26:38 AM, you wrote:
>> Nonetheless, I like a story / feature burndown at the project level,Yes. In my opinion, this is a sure sign that the story sizes are
> I agree with you if you managed to have fairly similar stories size/effort
> wise but when you have stories of different size/effort a story/feature
> burndown is misleading because it doesn't show you how much effort you
> still need to put into the project if you want to deliver them all.
too widely varying, and it's the thing to fix. Failing that, story
points or some other pure estimate works well.
> I spend at least one day every week discussing this same issue with myYes, but ... when you have 4 stories this actually has an effect.
> current customer's managers. They like the total effort based
> burnup/burndown but at the same time want a chart based on number of
> stories and give to the latter one more weight. But they communicate
> different messages! Example:
> - 10 stories for the release of product X
> - 5 of them have an estimate of 1 WUYU (whatever unit you use...)
> - 5 of them have an estimate of 3 WUYU
> - for various reason you cannot/don't want to split the bigger one down
> - 1 of the 3 WUYU stories yet to be done
> an effort based chart will show you that you still have 3 WUYU to do and
> you can use your velocity to commit to a date while a story/feature chart
> will show you only that you still have 1 story to do without an indication
> of what that means.
When you have 40 or 100, it turns out that the count tracks the work
units just fine. Law of large numbers hits quite early. Try it
> You can have situations in which people are worried because you still haveYes. I prefer to work with approximately two stories per programmer
> 4 stories to do not considering they are small, 1 WUYU stories and, at the
> same time, people not worried at all if you still have 2 story to do even
> if it is a 3 WUYU one.
per week. In that case ... this becomes a non issue.
Thus my "advice" is to use story count ... and do what has to be
done to make it work, which usually means many stories of
approximately the same size.
Find the simple path to what works and follow it,
always looking for a simpler path. -- Patrick D. Smith