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

RE: [scrumdevelopment] Sprint burndown chart - Tasks instead of hours on the vertical axis?

Expand Messages
  • Dominick Deinde
    I apologize. It was not my intent to be rude or condescending. Just trying to contribute to the discussion. Kind regards; Dominick T. Deinde Computer Systems
    Message 1 of 64 , Jun 1, 2012
    • 0 Attachment

      I apologize. It was not my intent to be rude or condescending. Just trying to contribute to the discussion.

       

      Kind regards;

       

      Dominick T. Deinde

      Computer Systems International

       

      This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any use or distribution of the email by any person other than the intended recipient is prohibited.

       

      P  please consider the environment before printing this e-mail

       

       

       

      From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of mj4scrum@...
      Sent: Friday, June 01, 2012 7:23 PM
      To: scrumdevelopment@yahoogroups.com
      Subject: Re: [scrumdevelopment] Sprint burndown chart - Tasks instead of hours on the vertical axis?

       




      I guess you're right. None of us doing Scrum have ever planned anything in our lives.  We should stop doing Scrum right now and go back to the Tayloristic approaches you're advocating.   

       

      Should we take down this list while we're at it?  Oh wait, that would require some planning, and we don't know how to do that!

      --mj

       


      On Jun 1, 2012, at 4:39 PM, "Dominick Deinde" <dominick@...> wrote:

       

      Michael;

       

      I think you are missing the point. Maybe you don’t have the fundamental of planning. Most people went into scrum because they don’t have to prove their skill like you will in PMI environment.  Just take 3 day class to become a Scrum Master. You may not learn anything from the 3 day class. For you to effectively identify tasks, you must know what you want to deliver. If you don’t know whether you want to make a cake or a fried bean, you won’t know where to start. Don’t memorize the scrum books. Try to understand how to apply them effectively.  Those lingos are nonsense to you because you don’t know the importance in project environments.  You utilize scrum as a methodology in a project environment. If you want me to define a project for you, don’t hesitate to ask. If you know the key factors in a project environment, you will understand the importance of planning. Don’t let me overwhelm you with lingos you may not understand J

       

      Kind regards;

       

      <image003.jpg>

      Dominick T. Deinde

      Computer Systems International

       

       

      This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any use or distribution of the email by any person other than the intended recipient is prohibited.

       

      P  please consider the environment before printing this e-mail

       

       

       

      From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Michael James
      Sent: Friday, June 01, 2012 5:46 PM
      To: scrumdevelopment@yahoogroups.com
      Subject: Re: [scrumdevelopment] Sprint burndown chart - Tasks instead of hours on the vertical axis?

       



      Yes, tasks are subordinate to PBIs (which do not have to be stories -- user stories aren't part of Scrum), so I'm glad to hear JIRA at least got that part right.  As for "capacity planning," many Scrum tools, including one I worked on years ago, try to appease buyers that adopt some of the lingo but aren't really doing Scrum.  So you'll find all kinds of nonsense like that in tools.

       

      In Scrum, a cross-functional, self organizing team commits to the goals they think they can accomplish in one fixed-length Sprint.  Therefore if the work is more challenging for their current skills, they'll commit to less of it until they gain those skills.  (BTW, most companies underestimate peoples' ability to learn new things.)  They may look at some numbers as a sanity check, such as how many PBIs they've historically completed.  But the team makes the decision, not the numbers.  Scrum may seem like witchcraft to you, but a lot of us have seen it work.

       

      --mj

      http://ScrumTrainingSeries.com

       

      On Jun 1, 2012, at 2:58 PM, Dominick Deinde wrote:




       

       

      Michael,

       

      One of the popular tools for scrum, Jira,  utilizes capacity planning for stories. The tool and others have sections for specifying tasks for stories.  You need to plan and track what you do in any methodology. How do you develop application software without having qualify and well trained Software Developers to develop the software? Do you think you can utilize a COBOL developer to develop java application ? Do you think it is possible to substitute a PO for a Software Developer ? How do you achieve your goals without setting up objectives and plans to reach the goals ? Unfortunately witchcraft does not work in software development LOL.

       

      Kind regards;

       

      <image002.jpg>

      Dominick T. Deinde

      Computer Systems International

       

      This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any use or distribution of the email by any person other than the intended recipient is prohibited.

       

      P  please consider the environment before printing this e-mail

       

       

       

      From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Michael James
      Sent: Friday, June 01, 2012 4:37 PM
      To: scrumdevelopment@yahoogroups.com
      Subject: Re: [scrumdevelopment] Sprint burndown chart - Tasks instead of hours on the vertical axis?

       



      Yes, in a traditional approach project managers allocate "resources," do things like capacity planning, and juggle "resources" around as needed.  Traditional project management still appears to work acceptably for some, or it would have died out by now.

       

      Conversely, Scrum does not have a project manager role, and you'll notice most Agile authors don't refer to people as "resources."  Scrum is intended for work that includes greater inherent uncertainty, where attempts at precise estimation and planning are more likely to lead to self deception and waste.  In Scrum, the collective ability of the learning team is our "resource."  It's more effective and respectful to refer to individuals as developers, team members, or even "people."  A dedicated, self organizing team with stable membership commits to Sprint Goals (typically represented by PBIs in user story form), comes up with their own tasks, and makes their own decisions about who volunteers for them.  In teams that are committed to learning, people volunteer for tasks on the edges of their own skills while others mentor them.  For an extreme example of this, see: http://csis.pace.edu/~grossman/dcs/XR4-PromiscuousPairing.pdf 

       

      --mj

      http://ScrumTrainingSeries.com

       

      On Jun 1, 2012, at 9:09 AM, Dominick Deinde wrote:





       

       

      Hello Andrew;

       

      If you don't know what to do to buy or make the type of cake, how are tasks going to help you?. You should identify this as an issue in your capacity planning and recommend looking for a resource with the expertise. How do you intend to deliver the story without qualify resources ?

       

      <image003.jpg>

      Dominick T. Deinde

      Computer Systems International

      The message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any use or distribution of the email by any person other than the intended recipient is prohibited.

       

      P  please consider the environment before printing this e-mail

       

       

       

      From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Andrew Burrows
      Sent: Friday, June 01, 2012 10:57 AM
      To: scrumdevelopment@yahoogroups.com
      Subject: Re: [scrumdevelopment] Re: Sprint burndown chart - Tasks instead of hours on the vertical axis?

       



      Hey Dominick,

       

      Thanks for the great feedback.

       

      1. I agree completely, as does the team. The process we've adopted is as a result of a long-term attempt to not work in isolation and it's working well. Why do I need to re-educate my team?

       

      2. If everything we do is based on the deliverables of the story - the "why" we're doing i




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