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

Re: Sprint burndown chart - Tasks instead of hours on the vertical axis?

Expand Messages
  • extremeprogrammer
    Sure, if you have extra constraints in your environment, then you need to do some more stuff. That didn t seem to be the situation being described. I actually
    Message 1 of 64 , Jun 4, 2012
    • 0 Attachment
      Sure, if you have extra constraints in your environment, then you need to do some more stuff. That didn't seem to be the situation being described.

      I actually don't "only plan every sprint". The development team I am working with works with the business side to give them as much information as they need. Some of what we do needs a few days of planned work. Some needs several months. We base our notion of timescales on recent sprint velocities, etc. Whatever is happening, we deliver new work into production every week usually (sometimes it's been a couple of weeks). So far, this has worked pretty well.

      This is not a perfect world I live in. It's one that has taken 8 months of effort to make much less imperfect than it was. And we'll continue to push it, not with kool-aid, but with reflection, respect, discussion and a shared interest in improving our lives. The environment I'm in allows this, for which I am grateful, although not everyone agrees with the direction we are taking.

      In the end though, everybody just needs to be reasonably happy with how they are working. If you are happy in your DOD environment, great! If Deidricke is happy in his, great! I am happy in mine, in the sense that it is amenable to change, I like the challenge of changing it, and I enjoy being a curmudgeon when it doesn't change quite how I want.

      Regards,

      Lance

      --- In scrumdevelopment@yahoogroups.com, Cass Dalton <cassdalton73@...> wrote:
      >
      > Unfortunately, not all of us get to live in that perfect world. Don't get
      > me wrong, I have drunk tge Scrum kool-aid. But I work in a very
      > traditional DOD environment. In order to push these new fangled ideas, I
      > have to convince the old guard that we can still deliver on time and on
      > budget and I need to compute earned value to report every month. You
      > suggest that you only plan every sprint. I have to make sure that feature
      > x is completed when I promised that feature x would be ready. And I can't
      > just tell the customer that they will get it when they get it. They have
      > to report to their superiors as well. And the first time the team misses
      > their Sprint goal, my superiors will want to know what the impact will be
      > to their budget. I can't answer that without actuals and a plan.
      > On Jun 2, 2012 3:14 PM, "extremeprogrammer" <LanceWalton@...> wrote:
      >
      > > **
      > >
      > >
      > > Hi Dominick.
      > >
      > > > What is the purpose for capturing "actuals" when you don't have anything
      > > to
      > > > compare with the "actuals" ?
      > >
      > > I agree with your rhetorical point. What is the purpose?
      > >
      > > In fact, Scrum does capture actuals. It captures actual facts about this
      > > team's recent 'performance' on this project. It captures the fact that this
      > > team achieved its sprint goal or not. It then uses that to actually feed
      > > back into the team's approach to future sprints.
      > >
      > > > How do you know a developer is not going to deliver when he/she supposed
      > > > to deliver?
      > >
      > > This question is nonsensical in Scrum, as it should be in any software
      > > process. The *team* delivers, not its members.
      > >
      > > What do you mean by "supposed"?
      > >
      > > > How do you manage customer/user delivery expectations ?
      > >
      > > By delivering early and often.
      > >
      > > > How do you know you won't complete sprint development within specified
      > > > sprint period ?
      > >
      > > You make your best guess about what you can achieve in a sprint using the
      > > most recent applicable information you have. i.e. the last sprint or two.
      > >
      > > You use burndown charts and be sensitive to the team's sprint signature.
      > >
      > > You trust the team to tell you as soon as they get a sense that the sprint
      > > goal is not achievable.
      > >
      > > ----
      > > If an organisation wants to compare what actually happens against a
      > > "baseline plan" (there is a connotation in that phrase which is
      > > oxymoronic), with a view to improving performance for future projects, I
      > > suggest they start smaller. One team, one sprint to the next. When they get
      > > competent at this, they can start trying to apply it more widely, if they
      > > still feel the need.
      > >
      > > But when they try to apply it wider, they need to keep in mind all of the
      > > confounding factors that will appear: a different team, different purposes,
      > > different goals, different "requirements", different stakeholders outside
      > > the team, different technologies, different environments. Too many
      > > questions.
      > >
      > > Regards,
      > >
      > > Lance
      > >
      > > --- In scrumdevelopment@yahoogroups.com, "Dominick Deinde" <dominick@>
      > > wrote:
      > > >
      > > > Hello Steve;
      > > >
      > > > The purpose for capturing "actuals" is to compare them to the baselined
      > > plan
      > > > in order to determine project performance. Let me turn the question
      > > around.
      > > > What is the purpose for capturing "actuals" when you don't have anything
      > > to
      > > > compare with the "actuals" ? Why not just capture completion date ? How
      > > do
      > > > you know a developer is not going to deliver when he/she supposed to
      > > deliver
      > > > ? How do you manage customer/user delivery expectations ? How do you know
      > > > you won't complete sprint development within specified sprint period ?
      > > Too
      > > > many questions J
      > > >
      > > >
      > > > Kind regards;
      > > >
      > > > Dominick T. Deinde
      > >
      > >
      > >
      >
    • extremeprogrammer
      Sure, if you have extra constraints in your environment, then you need to do some more stuff. That didn t seem to be the situation being described. I actually
      Message 64 of 64 , Jun 4, 2012
      • 0 Attachment
        Sure, if you have extra constraints in your environment, then you need to do some more stuff. That didn't seem to be the situation being described.

        I actually don't "only plan every sprint". The development team I am working with works with the business side to give them as much information as they need. Some of what we do needs a few days of planned work. Some needs several months. We base our notion of timescales on recent sprint velocities, etc. Whatever is happening, we deliver new work into production every week usually (sometimes it's been a couple of weeks). So far, this has worked pretty well.

        This is not a perfect world I live in. It's one that has taken 8 months of effort to make much less imperfect than it was. And we'll continue to push it, not with kool-aid, but with reflection, respect, discussion and a shared interest in improving our lives. The environment I'm in allows this, for which I am grateful, although not everyone agrees with the direction we are taking.

        In the end though, everybody just needs to be reasonably happy with how they are working. If you are happy in your DOD environment, great! If Deidricke is happy in his, great! I am happy in mine, in the sense that it is amenable to change, I like the challenge of changing it, and I enjoy being a curmudgeon when it doesn't change quite how I want.

        Regards,

        Lance

        --- In scrumdevelopment@yahoogroups.com, Cass Dalton <cassdalton73@...> wrote:
        >
        > Unfortunately, not all of us get to live in that perfect world. Don't get
        > me wrong, I have drunk tge Scrum kool-aid. But I work in a very
        > traditional DOD environment. In order to push these new fangled ideas, I
        > have to convince the old guard that we can still deliver on time and on
        > budget and I need to compute earned value to report every month. You
        > suggest that you only plan every sprint. I have to make sure that feature
        > x is completed when I promised that feature x would be ready. And I can't
        > just tell the customer that they will get it when they get it. They have
        > to report to their superiors as well. And the first time the team misses
        > their Sprint goal, my superiors will want to know what the impact will be
        > to their budget. I can't answer that without actuals and a plan.
        > On Jun 2, 2012 3:14 PM, "extremeprogrammer" <LanceWalton@...> wrote:
        >
        > > **
        > >
        > >
        > > Hi Dominick.
        > >
        > > > What is the purpose for capturing "actuals" when you don't have anything
        > > to
        > > > compare with the "actuals" ?
        > >
        > > I agree with your rhetorical point. What is the purpose?
        > >
        > > In fact, Scrum does capture actuals. It captures actual facts about this
        > > team's recent 'performance' on this project. It captures the fact that this
        > > team achieved its sprint goal or not. It then uses that to actually feed
        > > back into the team's approach to future sprints.
        > >
        > > > How do you know a developer is not going to deliver when he/she supposed
        > > > to deliver?
        > >
        > > This question is nonsensical in Scrum, as it should be in any software
        > > process. The *team* delivers, not its members.
        > >
        > > What do you mean by "supposed"?
        > >
        > > > How do you manage customer/user delivery expectations ?
        > >
        > > By delivering early and often.
        > >
        > > > How do you know you won't complete sprint development within specified
        > > > sprint period ?
        > >
        > > You make your best guess about what you can achieve in a sprint using the
        > > most recent applicable information you have. i.e. the last sprint or two.
        > >
        > > You use burndown charts and be sensitive to the team's sprint signature.
        > >
        > > You trust the team to tell you as soon as they get a sense that the sprint
        > > goal is not achievable.
        > >
        > > ----
        > > If an organisation wants to compare what actually happens against a
        > > "baseline plan" (there is a connotation in that phrase which is
        > > oxymoronic), with a view to improving performance for future projects, I
        > > suggest they start smaller. One team, one sprint to the next. When they get
        > > competent at this, they can start trying to apply it more widely, if they
        > > still feel the need.
        > >
        > > But when they try to apply it wider, they need to keep in mind all of the
        > > confounding factors that will appear: a different team, different purposes,
        > > different goals, different "requirements", different stakeholders outside
        > > the team, different technologies, different environments. Too many
        > > questions.
        > >
        > > Regards,
        > >
        > > Lance
        > >
        > > --- In scrumdevelopment@yahoogroups.com, "Dominick Deinde" <dominick@>
        > > wrote:
        > > >
        > > > Hello Steve;
        > > >
        > > > The purpose for capturing "actuals" is to compare them to the baselined
        > > plan
        > > > in order to determine project performance. Let me turn the question
        > > around.
        > > > What is the purpose for capturing "actuals" when you don't have anything
        > > to
        > > > compare with the "actuals" ? Why not just capture completion date ? How
        > > do
        > > > you know a developer is not going to deliver when he/she supposed to
        > > deliver
        > > > ? How do you manage customer/user delivery expectations ? How do you know
        > > > you won't complete sprint development within specified sprint period ?
        > > Too
        > > > many questions J
        > > >
        > > >
        > > > Kind regards;
        > > >
        > > > Dominick T. Deinde
        > >
        > >
        > >
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.