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

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

Expand Messages
  • Alan Dayley
    Wow. You should know that Michael is an experienced developer, project manager, Certified Scrum Trainer and Agile Coach. He knows what he is talking about,
    Message 1 of 64 , Jun 1, 2012
    • 0 Attachment
      Wow.  You should know that Michael is an experienced developer, project manager, Certified Scrum Trainer and Agile Coach.  He knows what he is talking about, not just spouting "Scrum lingo."  And he is trying to help you on his own time.

      You asked questions and we are giving you the answers as we know them and have EXPERIENCED them.  If you know our answers to be wrong, stop asking for them.

      Alan

      On Fri, 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;

       

      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 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 to use scrum we would task everything out as much as possible and then track progress through these tasks on our sprint burndown chart. This led to several bad habits:.

      • Swimline Dev Culture. If person A has these tasks, person B has their tasks and person C has their tasks, completion of the story can become several people working in isolation rather than collaborating on a solution. This is amplified on teams where the knowledge base is very unique per person (for example, a team with a programmer, an artist, an audio guy, a designer, a 3d guy, etc...)
      • Task-Based Development. We're agreed that the story is king? Breaking stories down into tasks can remove focus from the story and onto task completion. This leads to several other problems...
        • You don't know all your tasks in sprint planning. You only know the tasks you know about but this is the work we're tracking on a daily basis. To put it bluntly, you're tracking a percentage of the required work and you don't know how big that percentage is.
        • It doesn't matter if you've done all your tasks if your cake sucks. As a result of focusing on task completion and not story completion, you can get all known work verified and in the done column and still have things missing from the story.
      • People can't estimate time. Fairly self explanatory. Time estimates are typically not worth the time and money spent on discussing them and writing them on the cards.

      We tried a number of different solutions to change this behavior. For us, our epiphany was to remove tasking as a requirement. Instead, we switched focus to communication, collaboration and constant, hourly iteration. Our board doesn't have tasks, in the traditional sense; instead, the part of the board we used to use to hold our task cards contains a wide variety of items ranging from wireframes to drawings, sketches, tasks, ideas... whatever the team needs to communication, collaborate, iterate and achieve full story value.

       

      We also hold the Dude's Law to full effect: Value = Why/How. The "Why" we want the story is constant. So how do we adjust the "How" of our story? We have this conversation almost constantly. 

       

      So... the story being successful constitutes the largest business value, would you agree? If the story being successful requires all features completed to a potentially shippable state, then completing one task in a story constitutes zero business value and is actually a waste of money. It is more cost-effective to get to a piece of working software as quickly as possible in a sprint and figure out if it's going to work or not. 

       

      Hope this helps (and is coherent).

       

      Andrew

       

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

       

      Andrew, how do you deliver a story without completing the tasks to deliver the story ? It is good to have milestones as discussed but how do you achieve the milestones without predefined tasks ? I want a certain type of cake but I don’t know what to do to buy or make the type of cake J I guess you can just go to the store and pick up any cake J

       

       

       

      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 9:09 AM
      To: scrumdevelopment@yahoogroups.com
      Subject: Re: [scrumdevelopment] Re: Sprint burndown chart - Tasks instead of hours on the vertical axis?

       



      I dislike burndown charts for sprint work as I find the data to be misleading at worst, and inaccurate at best. I'm not concerned about the team's velocity for completing tasks, only that the product is progressing the way we expect it to and that the PO and dev team are happy with the work being produced. Instead of tasking, we instead create larger checkpoints for the story - for example, instead of writing a bunch of tasks to get to a piece of functionality, we just add that functionality as a checkpoint and gauge our progress against it; this gives us a more accurate idea of our product. And then we talk about it. A lot. Over and over again. And then more.

       

      If the team want to create tasks to help them work, great. But we don't track them, and we don't care if they're completed or not. All that matters is the story.

       

      Now, burn up charts to track long-term progress of the project via the product backlog are wonderful things, but more detail there seems like a different threads.

      On Fri, Jun 1, 2012 at 3:20 AM, Bob <bobbatemansbay@...> wrote:

       



      Hi Charles,

      My take is the Scrum Guide is trying to reduce waste and rework that may occur if planning for all sprint tasks-tasks that may be wrong or unnecessary. Where I worked, teams initially tasked out the entire sprint but found that many tasks (25%-30%) were unnecessary or incorrect as they worked the solution.

      As you say, the first days' worth of tasks is a minimum for the planning meeting but I believe doing the entire sprint is not a good idea. If the team tries to task out the whole sprint, they will increase the likelihood of planning for tasks that aren't needed or are wrong; wasting effort or causing rework.

      Bob Boyd
      http://implementingagile.blogspot.com/



      --- In scrumdevelopment@yahoogroups.com, Charles Bradley - Scrum Coach CSP CSM PSM I <chuck-lists2@...> wrote:
      >
      > Bob,
      >
      > > The Scrum Guide somewhat discourages tasking out the entire sprint where they talk about the second part of sprint planning, "Work planned for
      > the first days of the Sprint by the Development Team is decomposed to
      > units of one day or less by the end of this meeting."
      >
      >
      >
      > I didn't read it that way(discouraging).  I read the Scrum Guide as saying, at the minimum, "Work planned for
      > the first days of the Sprint by the Development Team is decomposed to
      > units of one day or less by the end of this meeting."
      >  
      > What one does beyond the minimum is up to the team to decide, in my view.
      >
      >
      > -------
      > Charles Bradley
      > http://www.ScrumCrazy.com
      >
      >
      >
      >
      >
      > >________________________________

      > > From: Bob <bobbatemansbay@...>


      > >To: scrumdevelopment@yahoogroups.com
      > >Sent: Friday, May 18, 2012 3:21 PM
      > >Subject: [scrumdevelopment] Re: Sprint burndown chart - Tasks instead of hours on the vertical axis?
      > >
      > >
      > >
      > >Hi Russell,
      > >
      > >We used hours on the vertical when teams first formed but eventually switched to using user story points. I believe that measuring the team's ability to estimate hours or to predict tasks has a limited appeal. On the plus side it's probably more familiar to the team while initially adopting Scrum but it tends to make estimates and task breakdowns more important (being visible on the Scrum Board) than user stories. After a few sprints, the teams switched to user story points and felt there was less pressure on them. Using story points put the focus on discrete bits of functionality and the team's performance whereas hours and tasks focused on individual performance.
      > >
      > >The Scrum Guide somewhat discourages tasking out the entire sprint where they talk about the second part of sprint planning, "Work planned for the first days of the Sprint by the Development Team is decomposed to units of one day or less by the end of this meeting." The key phrase is "first days of the Sprint".
      > >
      > >Good luck,
      > >
      > >Bob Boyd
      > >http://implementingagile.blogspot.com/
      > >



       

      --

      Andrew Burrows
      Managing Producer, Large Animal Games

      Call me: 212-989-4312

      Follow me: @readytoscrumble

       

       



       

      --
      Andrew Burrows
      Managing Producer, Large Animal Games

      Call me: 212-989-4312

      Follow me: @readytoscrumble

       







       

      --
      Andrew Burrows
      Managing Producer, Large Animal Games

      Call me: 212-989-4312

      Follow me: @readytoscrumble

       






       

       





       

       





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