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
    Alan; I am confused. Maybe the English language is becoming too complex for me. Help me to understand how you plan without having a plan. How do you know what
    Message 1 of 64 , Jun 1, 2012
    • 0 Attachment

      Alan;

       

      I am confused. Maybe the English language is becoming too complex for me.  Help me to understand how you plan without having a plan. How do you know what is done if you don’t know what you need to do ?

       

      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 Alan Dayley
      Sent: Friday, June 01, 2012 5:27 PM
      To: scrumdevelopment@yahoogroups.com
      Cc: <scrumdevelopment@yahoogroups.com>
      Subject: Re: [scrumdevelopment] Sprint burndown chart - Tasks instead of hours on the vertical axis?

       




      Just because a feature exists in Jira or any other "Scrum tool" does not mean it is part of Scrum or must be used.

       

      Read that again, please.

       

      In other words the functionality of a tool does not define Scrum.

       

      Yes, and most teams that use Jira, or any other "Scrum tool," use it's features in a way that prevents some ways of working better.

       

      Agile Planning: I need to plan, I don't need a plan.

       

      Agile Task Tracking: I need to know what is done, not what I have been doing. And if what I need done is not done yet, I need to have more conversations that drive getting it done and less conversations on why it is not done.

       

      Alan


      On Jun 1, 2012, at 2:58 PM, "Dominick Deinde" <dominick@...> 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 it and the value we hope to achieve - and we accept that we can only assume that we know what to do, why are tasks important? Isn't it more important to focus that time on how we can prove that we're wrong as early as possible in the sprint?

       

      3. I agree that practicing can result in better estimates. My response could seem a little flippant, but what's the point of spending time/money to learn to estimate better when we could be using that time/money learning how to create better software?

       

      I really appreciate you throwing these comments my way. I'm still curious to hear your answer to my earlier question -  if you don't know what to do to buy or make the type of cake, how are tasks going to help you?

       

      Andrew

      On Fri, Jun 1, 2012 at 11:49 AM, Dominick Deinde <dominick@...> wrote:

       

      Hello Andrew;

       

      If the method is working for you, that is great. I have few concerns regarding your discussion below.

       

      1.       Swimline Dev Culture.  The purpose of agile is to collaborate efforts in order to achieve defined goals. I consider working in isolation as a weakness of waterfall. You may want to re-educate your team.

      2.       Task Based Development. Use deliverable based development. Identify your deliverables in the story. Work with your SMEs to break the deliverables into components and tasks.

      3.      People can’t estimate.  “Practice makes perfect”. Just like everything we do in life, we have to practice regularly to achieve perfection. Maintain historical data for your estimates and use the historical data to guide your new estimates.

       

      Dominick

       

       

      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 Andrew Burrows
      Sent: Friday, June 01, 2012 10:01 AM


      To: scrumdevelopment@yahoogroups.com
      Subject: Re: [scrumdevelopment] Re: Sprint burndown chart - Tasks instead of hours on the vertical axis?

       



      Hey Dominick,

       

      Haha, fun question. I'd counter by asking  - if you don't know what to do to buy or make the type of cake, how are tasks going to help you?

       

      When we originally started t




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