Loading ...
Sorry, an error occurred while loading the content.
 

Re: Sizing tasks, story points, and done

Expand Messages
  • woynam
    I don t see why one can t have both. I overlay both an hour-based task burndown, and a point-based feature burn-up on our chart. I agree that the task-level
    Message 1 of 36 , Feb 1, 2008
      I don't see why one can't have both. I overlay both an hour-based task
      burndown, and a point-based feature burn-up on our chart.

      I agree that the task-level burn-down can be misleading, as it appears
      that work is being accomplished, but because it's spread across too
      many features, too few features are being completed. The feature
      burn-up graph show what's been completed.

      Mark


      --- In scrumdevelopment@yahoogroups.com, Mike Cohn <mike@...> wrote:
      >
      > I think a sprint burndown chart is wonderful when it is of hours. I
      > just haven't seen it be useful when it's of tasks. If you do, then you
      > should draw it no matter what anyone suggests here.
      >
      > I've blogged previously on why I think sprint and release estimates
      > should be in different units (see
      http://blog.mountaingoatsoftware.com/?p=6)
      > so I won't go through the whole discussion. It's also covered in
      > much more detail in Agile Estimating and Planning. To me the basic
      > argument is that I want a quick-to-apply relative measure of size for
      > the product backlog (story points fit the bill best there) but for a
      > sprint the team is about to start the work. If they can't put those
      > estimates into hours, I'm not sure they should be doing the work as
      > they probably haven't thought about it enough. Personally, I've never
      > seen the reason for task points. In writing the AEP book I sought out
      > teams doing that and what I found from them was most were really
      > thinking hours in their heads and knew a relationship between hours
      > and points but didn't want to call things hours because of working
      > with a dysfunctional manager who was overly focused on time tracking.
      >
      > Regards,
      > Mike Cohn
      > Author:
      > Agile Estimating and Planning
      > User Stories Applied
      > www.mountaingoatsoftware.com
      >
      >
      > On Jan 30, 2008, at 5:12 PM, Flávio Steffens de Castro wrote:
      >
      > > Im loving this thread :)
      > >
      > > Mike, in my specific case, there's some points to say: 1st) my team
      > > is new to SCRUM. 2nd) my team is new even into business (youngers,
      > > mostly).
      > >
      > > That's why Im defending the "sprint burndown chart" as a great way
      > > to motivate the team. I experienced this, and I can say that even if
      > > they get 5 seconds a day looking at the graph, that 5 seconds makes
      > > the people more confortable or nervous, depending on the graph!
      > >
      > > I agree with the no business value of the # of tasks. But since I
      > > will not use the hours estimating for each task, I need to find
      > > another way.
      > >
      > > What about, as someone said before, "task points"? If we realize
      > > that the "task points" are completely different from "story points",
      > > than we can assume that we have a nice estimating variable, with the
      > > Fibonacci, for example. I have no doubt that people can estimate
      > > better when we use relative metrics (as points).
      > >
      > > I was a little confused using task points, because I was not
      > > understanding the difference between task points and story points.
      > > For example: the sum of the story points for the sprint is 40. The
      > > sum of the task points for the sprint is 60! But if we understand
      > > that each variable has independent estimates, than we realize that
      > > 60 task-points arent bigger than 40 story-points.
      > >
      > > Phew! The only thing I know (by my experience) is that the burndown
      > > chart is a very nice metric to all the team and stakeholders :)
      > >
      > > Thanks for the great discussion
      > > Flavio
      > >
      > >
      > > 2008/1/30, Mike Cohn <mike@...>:
      > > I've seen teams do task burndowns before and I have to say that
      > > while it's nice in theory I'm not sure it was worth the 30 seconds
      > > of effort it took. If we go with the Tobias' goal of "each card is
      > > about a day" (which is what I recommend on average even when
      > > estimating hours) then all a team has to do is look at a task board,
      > > count the number of tasks left (or just guess by looking) and divide
      > > it by the number of days remaining. If the result is more than the #
      > > of team members they have too much work left "in theory." In
      > > practice, this isn't even as hard as I just describe--they eyeball
      > > the task board and can tell if they have too much or too little.
      > >
      > >
      > > This all, of course, assumes we've correctly made each card about a
      > > day. My theory is that taking the effort to make each card about a
      > > day takes longer than it does to put an estimate on a task that is
      > > 1-16 hours (and an average of about 6 hours).
      > >
      > > So: Task burndowns are nice in theory but they don't show anything a
      > > team can nearly instantly figure out just by looking at the # of
      > > cards on a wall. I've never seen a team pay much attention to one,
      > > including the few teams I've seen happy skipping the hour estimating.
      > >
      > > Not Estimating Task Hours: Perfectly fine for an experienced, stable
      > > team but you pretty much lose the value of a sprint burndown chart,
      > > which can be very helpful, especially when learning how much you can
      > > commit to, which is useful when new to Scrum or when team
      > > composition changes.
      > >
      > > If the team is spending so much time talking about hours that you
      > > want to save time by reclaiming that discussion, I suggest something
      > > else is wrong in sprint planning. The team needs to understood that
      > > the hours are their guesses, they can't be yelled at by management
      > > about them, etc. which means they can be lightweight and wrong.
      > >
      > > Regards,
      > >
      > > Mike Cohn
      > > Author:
      > > Agile Estimating and Planning
      > > User Stories Applied
      > > www.mountaingoatsoftware.com
      > >
      > >
      > > On Jan 30, 2008, at 3:48 PM, Flávio Steffens de Castro wrote:
      > >
      > >> Hi Mike,
      > >>
      > >> as I said, the # of tasks remaining at the burndown is a very
      > >> simple way to use the burndown. Im not very happy on estimating
      > >> hours to each task... and Im also not very happy with the "story
      > >> burndown", which give a view only when a story is "done". So you
      > >> will have a lot of days with ______________ lines.
      > >>
      > >> Im thinking to use the sprint burndown as a catalyst to motivate
      > >> the people. We all know that people are more confortable seeing
      > >> visual things (like graphs) than any other. So, the # of tasks
      > >> remaining may be a way to use the burndown more psycological than
      > >> really valuable.
      > >>
      > >> Since I dont simpatize with hours remaining, and I believe that any
      > >> other variable are a little confused to be used in the "y-axis",
      > >> the # tasks remaining should work. Very simples, not very valuable.
      > >> But still with a nice psycological effect.
      > >>
      > >> What do you think? Am I being a little fantasious?
      > >>
      > >> Thanks
      > >> Flavio
      > >>
      > >>
      > >> 2008/1/30, Mike Cohn <mike@...>:
      > >> What a great topic.
      > >>
      > >>
      > >> I taught a Scrum class yesterday and an agile estimating and
      > >> planning class today. I'll say here what I said in each class: "The
      > >> purpose of sprint planning is to figure out and make a reasonable
      > >> commitment to a set of product backlog items. The purpose is not to
      > >> come up with the tasks and hours. Breaking a user story (product
      > >> backlog item) into tasks and hours is a tool we use to figure out
      > >> what we can commit to. But it is important to remember that the
      > >> goal of the meeting is to figure out how much to commit to, not to
      > >> come up with the hours. If someone could receive divine inspiration
      > >> that said 'you can do these four user stories next sprint' I would
      > >> be happy to end sprint planning there."
      > >>
      > >> So, the hours are a tool to use in making a commitment to the user
      > >> stories on the product backlog.
      > >>
      > >> With that in mind, I do think that breaking user stories into tasks
      > >> and estimating the hours is--as Jeff said--useful to new teams. As
      > >> a team becomes comfortable with Scrum if they are comfortable
      > >> making a commitment to work without hours (under the assumption
      > >> that all tasks are about the same size) then I'm OK with that. I
      > >> would point out two arguments to this, though:
      > >> a) A sprint burndown chart of "# of tasks remaining" will be far
      > >> less valuable than one of # of hours remaining. This means a team
      > >> should only abandon hours once they are good at planning to the
      > >> point where they also rarely need to drop work mid-sprint
      > >> b) during sprint planning the vast majority of time should be spent
      > >> in discussing the product needs, how we'll build it (product
      > >> design) and the tasks involved (technical design) rather than the
      > >> hours for each task. I would say that 90% of the time should be
      > >> about what the work is rather than about the number to put on it.
      > >> So, any savings from dropping hour discussion is likely to be
      > >> negligible.
      > >>
      > >> Interesting discussion.
      > >>
      > >> Regards,
      > >> Mike Cohn
      > >> Author:
      > >> Agile Estimating and Planning
      > >> User Stories Applied
      > >> www.mountaingoatsoftware.com
      > >>
      > >>
      > >> On Jan 30, 2008, at 7:41 AM, Tobias Mayer wrote:
      > >>
      > >>> This sounds good, Jeff. It is encouraging to hear from many recent
      > >>> posts that there is a trend away from estimating and burning down on
      > >>> hours; it was the one thing in "original Scrum" that always felt
      > >>> wrong.
      > >>>
      > >>> I do disagree with you (and George Dinwiddie in the other thread on
      > >>> this topic) that new teams need to estimate in hours, that somehow
      > >>> it
      > >>> helps them. I have not found that, indeed my experience has been the
      > >>> opposite.
      > >>>
      > >>> For the past 3+ years I have not asked teams to estimate tasks at
      > >>> all,
      > >>> in any unit, beyond thinking of them as "small enough to move
      > >>> across the
      > >>> taskboard in a single day". Prior to that time I saw many disgrutled
      > >>> developers feeling like they were being micromanaged by the SM and/
      > >>> or PO
      > >>> by having to update hours remaining on every task. Simpler is
      > >>> better,
      > >>> whether a team is new to Scrum or has years of experience.
      > >>>
      > >>> I tend to burn down on both Story Points and actual stories, to
      > >>> give two
      > >>> different perspectives on progress. In both cases only completed
      > >>> stories move the line.
      > >>>
      > >>> Tobias
      > >>>
      > >>> --- In scrumdevelopment@yahoogroups.com, "Jeff Sutherland"
      > >>> <jeff.sutherland@> wrote:
      > >>> >
      > >>> > Recently, new Scrum teams in one of the world's largest healthcare
      > >>> > companies decided to measure burndown in their sprints only by
      > >>> story
      > >>> > points for the companies most critical project with a hard
      > >>> delivery
      > >>> > date that was one year earlier that the predicted waterfall
      > >>> date. They
      > >>> > only burned down when a story was done and done meant fully
      > >>> tested at
      > >>> > the functional level, not just unit tested as at many companies.
      > >>> And
      > >>> > they met the date, one year early.
      > >>> >
      > >>> > Why? Because they understood that tasks complete with stories
      > >>> > unfinished just means a lot of work in progress with potential
      > >>> major
      > >>> > integration problems when you really test the code in a global
      > >>> build
      > >>> > of the system. Also they know that one hour of work for one
      > >>> developer
      > >>> > could be 10 hours of work for another developer, that research
      > >>> shows
      > >>> > that hours have no relationship whatsoever to quality and that one
      > >>> > team may be disrupted and take 10 hours to do what another team
      > >>> might
      > >>> > need 250 hours to do. Hours are completely useless as a
      > >>> measurement
      > >>> > except when you have to cut a check to a consultant whether he
      > >>> > delivers anything or not. You certainly don't need them to pay
      > >>> > developers since they are paid the same amount every month
      > >>> independent
      > >>> > of hours they work (or stuff they have delivered).
      > >>> >
      > >>> > Published research shows that hunans are terrible at estimating
      > >>> > anything in hours. However, they are pretty good at relative
      > >>> sizing.
      > >>> > They know roughtly what S, M, L, and XL t-shirt sizes mean even if
      > >>> > they can't guess the weight of th people. And their brains are
      > >>> wired
      > >>> > for a growth pattern seen everywhere in nature that can be
      > >>> described
      > >>> > by a Fibonacci series.
      > >>> >
      > >>> > Therefore, you will get better estimates for anything using
      > >>> Fibonacci
      > >>> > whether they be stories, t-shirts, tasks, or when dinmer might be
      > >>> > ready.
      > >>> >
      > >>> > Nevertheless, new teams often have management that demands
      > >>> hours, just
      > >>> > like they used to demand waterfall. It doesn't work but it's
      > >>> familiar
      > >>> > and they are addicted. So it is easier to just give it to them.
      > >>> That's
      > >>> > why I agree with Mike Cohn that new teams might be best at
      > >>> estimating
      > >>> > stories in story points and tasks in hours.
      > >>> >
      > >>> > However, at Google in Trondheim recntly, where they are doing
      > >>> > everything in Scrum and the typical developer has been head of the
      > >>> > Internet task force for the last five years, my recommendation
      > >>> was to
      > >>> > forget hours. That would just slow them down. Don't even estimate
      > >>> > velocity as these guys know roughly what they can do and can get
      > >>> to
      > >>> > accurate velocity by measuring it from Sprint to Sprint and use
      > >>> > "Yesterday's Weather" as a best practice pattern for pulling
      > >>> stories
      > >>> > into a Sprint. Only estimate stories in story points and only burn
      > >>> > down completed stories.
      > >>> >
      > >>> > Of course, at Google, they have no managers looking over their
      > >>> > shoulder that are addicted to hours, so they do not have the
      > >>> > impediments that most organizations have so they will go faster
      > >>> out of
      > >>> > the gate.
      > >>> >
      > >>> > Scrum was designed for extreme performance through inspecting and
      > >>> > adapting. Most high performance teams I have worked with have used
      > >>> > hours in the early days as training wheels and they abandoned
      > >>> them as
      > >>> > their velocity went ballistic.
      > >>> >
      > >>> > Last year I asked my Chief Product Owner if he felt
      > >>> uncomfortable that
      > >>> > we were no longer keeping track of hours. He said yes, that some
      > >>> > nights he had knots in his stomach when he went to bed. I asked
      > >>> him if
      > >>> > he wanted to go back to the rigorous hourly measurement that we
      > >>> had
      > >>> > used for several years. He said "No!" When I asked why not, he
      > >>> said,
      > >>> > "It will slow the teams down!" So our Product Owner has
      > >>> inspected and
      > >>> > adapted and decided to accept a "perceived risk" in exchange for
      > >>> > velocity and maximized business value.
      > >>> >
      > >>> > Fear not. I still teach how to estimate sprint backlog by measurng
      > >>> > tasks in hours in Scrum training since most of those new to
      > >>> Scrum need
      > >>> > it. In fact, until they can demonstrate they can pass the Nokia
      > >>> test
      > >>> > for doing Scrum they should not think about anything else. But
      > >>> that is
      > >>> > another whole discussion.
      > >>> >
      > >>> > --
      > >>> > Jeff Sutherland
      > >>> > jeff.sutherland@
      > >>> >
      > >>>
      > >>>
      > >>
      > >>
      > >>
      > >>
      > >>
      > >>
      > >> --
      > >> _____________________
      > >> Flavio Steffens de Castro
      > >>
      > >
      > >
      > >
      > >
      > >
      > > --
      > > _____________________
      > > Flavio Steffens de Castro
      > >
      > >
      >
    • mkg6_hotmail
      Flávio, I have the same experience. It gives people a good feeling that they see the chart going down and a sense of proudness when they sign off a task. ...
      Message 36 of 36 , Feb 6, 2008
        Flávio,

        I have the same experience. It gives people a good feeling that they
        see the chart going down and a sense of proudness when they sign off a
        task.


        --- In scrumdevelopment@yahoogroups.com, "Flávio Steffens de Castro"
        <flavio.steffens@...> wrote:
        >
        > Does anyone has the same scenary than I? Teams with young people,
        newbies to
        > SCRUM and also newbies to development?
      Your message has been successfully submitted and would be delivered to recipients shortly.