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

Burndown charts and late finishers

Expand Messages
  • Simon Morris
    Hello all, I mainly wanted to introduce myself to the group as a newbie but also ask a quick question. I ve been following the group for a while and I find the
    Message 1 of 15 , Apr 20, 2012
    • 0 Attachment
      Hello all,

      I mainly wanted to introduce myself to the group as a newbie but also ask a quick question.

      I've been following the group for a while and I find the insights really valuable. Thanks for the time you spend on this community.

      So - in our sprints we consistently start slow and have a big finish. You can see our latest burndown chart here.


      This isn't necessarily a problem as we ship features on time and with the correct quality, but it is always a slight feeling of panic as we drift away from the "Ideal" line.

      I don't really want to push the group to start stronger as we consistently deliver successfully and putting more effort into the first couple of days would just serve to make the chart prettier.

      Does anyone else see this as a warning sign - maybe I should just stop checking the burndown chart in the first half of the sprint :-)

      Thanks

      Simon


    • simonmorris7809
      Hello all, I mainly wanted to introduce myself to the group as a newbie but also ask a quick question. I ve been following the group for a while and I find the
      Message 2 of 15 , Apr 27, 2012
      • 0 Attachment
        Hello all,

        I mainly wanted to introduce myself to the group as a newbie but also ask a quick question.

        I've been following the group for a while and I find the insights really valuable. Thanks for the time you spend on this community.

        So - in our sprints we consistently start slow and have a big finish. You can see our latest burndown chart here.

        https://plus.google.com/105300838558555602864/posts/LMfs4LmkEzJ

        This isn't necessarily a problem as we ship features on time and with the correct quality, but it is always a slight feeling of panic as we drift away from the "Ideal" line.

        I don't really want to push the group to start stronger as we consistently deliver successfully and putting more effort into the first couple of days would just serve to make the chart prettier.

        Does anyone else see this as a warning sign - maybe I should just stop checking the burndown chart in the first half of the sprint :-)

        Thanks
      • Kurt Häusler
        No its fine. Ideal lines are not really recommended anyway. The curve on your chart is pretty normal.
        Message 3 of 15 , May 8, 2012
        • 0 Attachment
          No its fine. Ideal lines are not really recommended anyway. The curve
          on your chart is pretty normal.

          On Fri, Apr 20, 2012 at 7:34 PM, Simon Morris <mozrat@...> wrote:
          >
          >
          >
          > Hello all,
          >
          >
          > I mainly wanted to introduce myself to the group as a newbie but also ask
          > a quick question.
          >
          > I've been following the group for a while and I find the insights really
          > valuable. Thanks for the time you spend on this community.
          >
          > So - in our sprints we consistently start slow and have a big finish. You
          > can see our latest burndown chart here.
          >
          > https://plus.google.com/105300838558555602864/posts/LMfs4LmkEzJ
          >
          > This isn't necessarily a problem as we ship features on time and with the
          > correct quality, but it is always a slight feeling of panic as we drift away
          > from the "Ideal" line.
          >
          > I don't really want to push the group to start stronger as we consistently
          > deliver successfully and putting more effort into the first couple of days
          > would just serve to make the chart prettier.
          >
          > Does anyone else see this as a warning sign - maybe I should just stop
          > checking the burndown chart in the first half of the sprint :-)
          >
          > Thanks
          >
          > Simon
          >
          >
          >
        • Steve Ropa
          +1 This is a very normal burndown. I for one hate the ideal line, as I ve seen too many teams chase this phantasm. This leads them to want to do the
          Message 4 of 15 , May 8, 2012
          • 0 Attachment
            +1

            This is a very normal burndown. I for one hate the ideal line, as I've seen too many teams chase this phantasm. This leads them to want to do the "traditional" PM thing of changing reality to match the chart, rather than let the chart be a dispassionate view of reality.

            Kurt Häusler &lt;kurt.haeusler@...&gt; wrote:

             

            No its fine. Ideal lines are not really recommended anyway. The curve
            on your chart is pretty normal.

            On Fri, Apr 20, 2012 at 7:34 PM, Simon Morris <mozrat@...> wrote:
            >
            >
            >
            > Hello all,
            >
            >
            > I mainly wanted to introduce myself to the group as a newbie but also ask
            > a quick question.
            >
            > I've been following the group for a while and I find the insights really
            > valuable. Thanks for the time you spend on this community.
            >
            > So - in our sprints we consistently start slow and have a big finish. You
            > can see our latest burndown chart here.
            >
            > https://plus.google.com/105300838558555602864/posts/LMfs4LmkEzJ
            >
            > This isn't necessarily a problem as we ship features on time and with the
            > correct quality, but it is always a slight feeling of panic as we drift away
            > from the "Ideal" line.
            >
            > I don't really want to push the group to start stronger as we consistently
            > deliver successfully and putting more effort into the first couple of days
            > would just serve to make the chart prettier.
            >
            > Does anyone else see this as a warning sign - maybe I should just stop
            > checking the burndown chart in the first half of the sprint :-)
            >
            > Thanks
            >
            > Simon
            >
            >
            >

          • Bret Wortman
            Ignore the ideal line -- it s a marketing tool created by the software tools because some customer demanded it. Ignore it, or demand that your software tool
            Message 5 of 15 , May 8, 2012
            • 0 Attachment
              Ignore the ideal line -- it's a marketing tool created by the software tools because some customer demanded it. Ignore it, or demand that your software tool provider make it optional. In fact, if you search VersionOne's ideaspace, you'll find my own request for this feature and you can vote it up. </shamelessplug>.

              The ideal line only creates the impression that work should be progressing at some consistent rate, which is a myth. Photoshop it out if you have to, but don't let management think it's normal or expected.


              Bret Wortman



              On Tue, May 8, 2012 at 10:01 AM, Steve Ropa <theropas@...> wrote:
               

              +1

              This is a very normal burndown. I for one hate the ideal line, as I've seen too many teams chase this phantasm. This leads them to want to do the "traditional" PM thing of changing reality to match the chart, rather than let the chart be a dispassionate view of reality.



              Kurt Häusler &lt;kurt.haeusler@...&gt; wrote:

               

              No its fine. Ideal lines are not really recommended anyway. The curve
              on your chart is pretty normal.

              On Fri, Apr 20, 2012 at 7:34 PM, Simon Morris <mozrat@...> wrote:
              >
              >
              >
              > Hello all,
              >
              >
              > I mainly wanted to introduce myself to the group as a newbie but also ask
              > a quick question.
              >
              > I've been following the group for a while and I find the insights really
              > valuable. Thanks for the time you spend on this community.
              >
              > So - in our sprints we consistently start slow and have a big finish. You
              > can see our latest burndown chart here.
              >
              > https://plus.google.com/105300838558555602864/posts/LMfs4LmkEzJ
              >
              > This isn't necessarily a problem as we ship features on time and with the
              > correct quality, but it is always a slight feeling of panic as we drift away
              > from the "Ideal" line.
              >
              > I don't really want to push the group to start stronger as we consistently
              > deliver successfully and putting more effort into the first couple of days
              > would just serve to make the chart prettier.
              >
              > Does anyone else see this as a warning sign - maybe I should just stop
              > checking the burndown chart in the first half of the sprint :-)
              >
              > Thanks
              >
              > Simon
              >
              >
              >


            • Mark Levison
              I replied on Google+. Burndown Charts lie. I generally recommend to my clients that they don t use them. Please help us by showing snapshots of your story
              Message 6 of 15 , May 8, 2012
              • 0 Attachment
                I replied on Google+.
                Burndown Charts lie. I generally recommend to my clients that they don't use them.
                Please help us by showing snapshots of your story wall.

                How small are your stories? How many stories do you commit to a Sprint? 
                How many people work on each Story?
                What would stop you finishing your first small Story by the end of day 3?

                Cheers
                Mark

                On Fri, Apr 20, 2012 at 1:34 PM, Simon Morris <mozrat@...> wrote:
                 

                Hello all,


                I mainly wanted to introduce myself to the group as a newbie but also ask a quick question.

                I've been following the group for a while and I find the insights really valuable. Thanks for the time you spend on this community.

                So - in our sprints we consistently start slow and have a big finish. You can see our latest burndown chart here.


                This isn't necessarily a problem as we ship features on time and with the correct quality, but it is always a slight feeling of panic as we drift away from the "Ideal" line.

                I don't really want to push the group to start stronger as we consistently deliver successfully and putting more effort into the first couple of days would just serve to make the chart prettier.

                Does anyone else see this as a warning sign - maybe I should just stop checking the burndown chart in the first half of the sprint :-)

                Thanks

                Simon



              • Steve
                Simon - if it isn t a problem, why change anything? Scrum is about delivering business value not having pretty charts! I personally do not use a Sprint
                Message 7 of 15 , May 8, 2012
                • 0 Attachment
                  Simon - if it isn't a problem, why change anything?

                  Scrum is about delivering business value not having pretty charts!

                  I personally do not use a Sprint Burndown, the lowest level of burndown I use is for a Release.

                  Anyway, there is no such thing as an ideal line, it is a forecast; if we lived in an ideal world with robots doing the work, then a move away from 'an ideal line' would indicate a problem. However, we are people and groups of people behave differently.

                  --- In scrumdevelopment@yahoogroups.com, "simonmorris7809" <mozrat@...> wrote:
                  >
                  > Hello all,
                  >
                  > I mainly wanted to introduce myself to the group as a newbie but also ask a quick question.
                  >
                  > I've been following the group for a while and I find the insights really valuable. Thanks for the time you spend on this community.
                  >
                  > So - in our sprints we consistently start slow and have a big finish. You can see our latest burndown chart here.
                  >
                  > https://plus.google.com/105300838558555602864/posts/LMfs4LmkEzJ
                  >
                  > This isn't necessarily a problem as we ship features on time and with the correct quality, but it is always a slight feeling of panic as we drift away from the "Ideal" line.
                  >
                  > I don't really want to push the group to start stronger as we consistently deliver successfully and putting more effort into the first couple of days would just serve to make the chart prettier.
                  >
                  > Does anyone else see this as a warning sign - maybe I should just stop checking the burndown chart in the first half of the sprint :-)
                  >
                  > Thanks
                  >
                • Wouter Lagerweij
                  Hi Simon, The ideal line is not very useful, but not finishing anything for the first week would worry me. And it also seems that after not finishing the first
                  Message 8 of 15 , May 8, 2012
                  • 0 Attachment
                    Hi Simon,

                    The ideal line is not very useful, but not finishing anything for the first week would worry me.
                    And it also seems that after not finishing the first week, you added stories to the sprint?

                    It really helps if you can get stories small enough to finish in a day or two. If you don't have that, then this doesn't mean anything (except: 'stories too big'). Of course, if that's the case, then your burndown *also* doesn't really mean anything...

                    Wouter 

                    On Fri, Apr 20, 2012 at 7:34 PM, Simon Morris <mozrat@...> wrote:
                     

                    Hello all,


                    I mainly wanted to introduce myself to the group as a newbie but also ask a quick question.

                    I've been following the group for a while and I find the insights really valuable. Thanks for the time you spend on this community.

                    So - in our sprints we consistently start slow and have a big finish. You can see our latest burndown chart here.


                    This isn't necessarily a problem as we ship features on time and with the correct quality, but it is always a slight feeling of panic as we drift away from the "Ideal" line.

                    I don't really want to push the group to start stronger as we consistently deliver successfully and putting more effort into the first couple of days would just serve to make the chart prettier.

                    Does anyone else see this as a warning sign - maybe I should just stop checking the burndown chart in the first half of the sprint :-)

                    Thanks

                    Simon





                    --
                    Wouter Lagerweij         | wouter@...
                  • vercinget_xx
                    When I first looked at the graph, I thought your actuals were actually *too* close to the ideal. The line *should* actually go up before it goes down, because
                    Message 9 of 15 , May 8, 2012
                    • 0 Attachment
                      When I first looked at the graph, I thought your actuals were actually *too* close to the ideal. The line *should* actually go up before it goes down, because no amount of analysis will ever result in knowing all the tasks and the effort required in advance.

                      But then I realized your burndown is showing the completion of stories, not tasks! So that left me pondering, do most you you all burn down stories within a sprint, or do you burn down tasks?

                      The way I've always done it is, after the team commits to stories in the planning meeting, they then brainstorm all the tasks and estimate them in hours. Summing all the hours then provides a rough cross-check of the committment (i.e. if the task hours sum to about 50% - 70% of the total working hours available, you're probably within the ballpark. If the total hours exceed 70% of the available time, then the team is probably over-committed). During the sprint, the team updates tasks with hours remaining, so they always have a snapshot of how much work is left, and if the trend starts to look like they won't make it, they can adjust their plans in order to meet the sprint goal. I show a story burndown sprint-by-sprint, but not within a sprint. Note that the Team *is* encouraged to tackle the stories one at a time and complete them in sequence. I'd much rather have nine stories "done, done" and one never even touched, than 10 stories 90% completed.

                      So what do you all use? Within a sprint, do you burn down tasks or stories?

                      -Jeff

                      --- In scrumdevelopment@yahoogroups.com, "simonmorris7809" <mozrat@...> wrote:
                      >
                      > Hello all,
                      >
                      > I mainly wanted to introduce myself to the group as a newbie but also ask a quick question.
                      >
                      > I've been following the group for a while and I find the insights really valuable. Thanks for the time you spend on this community.
                      >
                      > So - in our sprints we consistently start slow and have a big finish. You can see our latest burndown chart here.
                      >
                      > https://plus.google.com/105300838558555602864/posts/LMfs4LmkEzJ
                      >
                      > This isn't necessarily a problem as we ship features on time and with the correct quality, but it is always a slight feeling of panic as we drift away from the "Ideal" line.
                      >
                      > I don't really want to push the group to start stronger as we consistently deliver successfully and putting more effort into the first couple of days would just serve to make the chart prettier.
                      >
                      > Does anyone else see this as a warning sign - maybe I should just stop checking the burndown chart in the first half of the sprint :-)
                      >
                      > Thanks
                      >
                    • Wouter Lagerweij
                      Hi Jeff, What you describe seems to be textbook , in that it s exactly as it was put in the scrum guide, and many scrum books. No problems there. What I
                      Message 10 of 15 , May 8, 2012
                      • 0 Attachment
                        Hi Jeff,

                        What you describe seems to be 'textbook', in that it's exactly as it was put in the scrum guide, and many scrum books. No problems there.

                        What I normally do is try to put focus on finishing stories by doing the sprint burndown on a story points (story in done means points on the chart). I try to leave hours as far out of the discussion as I can, though I do encourage a team to make their tasks as small as possible, preferably so that they can do them within half a day, so there is some implicit time estimation there.

                        In those same teams, which are usually the ones where the stories are still rather large, I often have a burn-up chart of tasks to complement the burn-down of stories. This shows that there is progress, even if stories aren't yet in Done. I've seen that become too much of a focus, though, so I'm not sure about whether that practice is one I should keep up.

                        Some others don't do the burndown at all and/or burn down stories (not story-points), without assigning points to the stories at all. They consistently have their stories small enough that they can plan based on ability to do 8-10 stories per sprint (for example).

                        Wouter

                        On Tue, May 8, 2012 at 6:30 PM, vercinget_xx <jheinen@...> wrote:
                         

                        When I first looked at the graph, I thought your actuals were actually *too* close to the ideal. The line *should* actually go up before it goes down, because no amount of analysis will ever result in knowing all the tasks and the effort required in advance.

                        But then I realized your burndown is showing the completion of stories, not tasks! So that left me pondering, do most you you all burn down stories within a sprint, or do you burn down tasks?

                        The way I've always done it is, after the team commits to stories in the planning meeting, they then brainstorm all the tasks and estimate them in hours. Summing all the hours then provides a rough cross-check of the committment (i.e. if the task hours sum to about 50% - 70% of the total working hours available, you're probably within the ballpark. If the total hours exceed 70% of the available time, then the team is probably over-committed). During the sprint, the team updates tasks with hours remaining, so they always have a snapshot of how much work is left, and if the trend starts to look like they won't make it, they can adjust their plans in order to meet the sprint goal. I show a story burndown sprint-by-sprint, but not within a sprint. Note that the Team *is* encouraged to tackle the stories one at a time and complete them in sequence. I'd much rather have nine stories "done, done" and one never even touched, than 10 stories 90% completed.

                        So what do you all use? Within a sprint, do you burn down tasks or stories?

                        -Jeff



                        --- In scrumdevelopment@yahoogroups.com, "simonmorris7809" <mozrat@...> wrote:
                        >
                        > Hello all,
                        >
                        > I mainly wanted to introduce myself to the group as a newbie but also ask a quick question.
                        >
                        > I've been following the group for a while and I find the insights really valuable. Thanks for the time you spend on this community.
                        >
                        > So - in our sprints we consistently start slow and have a big finish. You can see our latest burndown chart here.
                        >
                        > https://plus.google.com/105300838558555602864/posts/LMfs4LmkEzJ
                        >
                        > This isn't necessarily a problem as we ship features on time and with the correct quality, but it is always a slight feeling of panic as we drift away from the "Ideal" line.
                        >
                        > I don't really want to push the group to start stronger as we consistently deliver successfully and putting more effort into the first couple of days would just serve to make the chart prettier.
                        >
                        > Does anyone else see this as a warning sign - maybe I should just stop checking the burndown chart in the first half of the sprint :-)
                        >
                        > Thanks
                        >




                        --
                        Wouter Lagerweij         | wouter@...
                      • Whyves
                        In our teams, we burndown tasks. I agree with the general concept that at the end, the most important thing is to deliver done stories and that the burdown is
                        Message 11 of 15 , May 8, 2012
                        • 0 Attachment
                          In our teams, we burndown tasks. I agree with the general concept that at the end, the most important thing is to deliver done stories and that the burdown is not that important. However, I do not think that they are evil. I think they convey important information, especially when dealing with more junior teams. For example, if the burndown stays flat for a while it can help raise the question as to whether the team is lost or gold plating. Granted you can catch this at the daily but the curve is another reminder.

                          Personally, I find the burndowns useful but I must admit that I sometimes need to remind management that the curves are a tool for the team and not a metric to track down for reporting.


                          --- In scrumdevelopment@yahoogroups.com, "vercinget_xx" <jheinen@...> wrote:
                          >
                          > When I first looked at the graph, I thought your actuals were actually *too* close to the ideal. The line *should* actually go up before it goes down, because no amount of analysis will ever result in knowing all the tasks and the effort required in advance.
                          >
                          > But then I realized your burndown is showing the completion of stories, not tasks! So that left me pondering, do most you you all burn down stories within a sprint, or do you burn down tasks?
                          >
                          > The way I've always done it is, after the team commits to stories in the planning meeting, they then brainstorm all the tasks and estimate them in hours. Summing all the hours then provides a rough cross-check of the committment (i.e. if the task hours sum to about 50% - 70% of the total working hours available, you're probably within the ballpark. If the total hours exceed 70% of the available time, then the team is probably over-committed). During the sprint, the team updates tasks with hours remaining, so they always have a snapshot of how much work is left, and if the trend starts to look like they won't make it, they can adjust their plans in order to meet the sprint goal. I show a story burndown sprint-by-sprint, but not within a sprint. Note that the Team *is* encouraged to tackle the stories one at a time and complete them in sequence. I'd much rather have nine stories "done, done" and one never even touched, than 10 stories 90% completed.
                          >
                          > So what do you all use? Within a sprint, do you burn down tasks or stories?
                          >
                          > -Jeff
                          >
                          > --- In scrumdevelopment@yahoogroups.com, "simonmorris7809" <mozrat@> wrote:
                          > >
                          > > Hello all,
                          > >
                          > > I mainly wanted to introduce myself to the group as a newbie but also ask a quick question.
                          > >
                          > > I've been following the group for a while and I find the insights really valuable. Thanks for the time you spend on this community.
                          > >
                          > > So - in our sprints we consistently start slow and have a big finish. You can see our latest burndown chart here.
                          > >
                          > > https://plus.google.com/105300838558555602864/posts/LMfs4LmkEzJ
                          > >
                          > > This isn't necessarily a problem as we ship features on time and with the correct quality, but it is always a slight feeling of panic as we drift away from the "Ideal" line.
                          > >
                          > > I don't really want to push the group to start stronger as we consistently deliver successfully and putting more effort into the first couple of days would just serve to make the chart prettier.
                          > >
                          > > Does anyone else see this as a warning sign - maybe I should just stop checking the burndown chart in the first half of the sprint :-)
                          > >
                          > > Thanks
                          > >
                          >
                        • George Dinwiddie
                          Simon ... Could it be a sign of too much Work In Progress? I discuss shapes of burndown charts in my Better Software article,
                          Message 12 of 15 , May 8, 2012
                          • 0 Attachment
                            Simon

                            On 4/27/12 12:43 PM, simonmorris7809 wrote:
                            > Hello all,
                            >
                            > I mainly wanted to introduce myself to the group as a newbie but also
                            > ask a quick question.
                            >
                            > I've been following the group for a while and I find the insights
                            > really valuable. Thanks for the time you spend on this community.
                            >
                            > So - in our sprints we consistently start slow and have a big finish.
                            > You can see our latest burndown chart here.
                            >
                            > https://plus.google.com/105300838558555602864/posts/LMfs4LmkEzJ
                            >
                            > This isn't necessarily a problem as we ship features on time and with
                            > the correct quality, but it is always a slight feeling of panic as we
                            > drift away from the "Ideal" line.
                            >
                            > I don't really want to push the group to start stronger as we
                            > consistently deliver successfully and putting more effort into the
                            > first couple of days would just serve to make the chart prettier.
                            >
                            > Does anyone else see this as a warning sign - maybe I should just
                            > stop checking the burndown chart in the first half of the sprint :-)

                            Could it be a sign of too much Work In Progress? I discuss shapes of
                            burndown charts in my Better Software article,
                            http://idiacomputing.com/pub/BetterSoftware-BurnCharts.pdf

                            - George

                            --
                            ----------------------------------------------------------------------
                            * George Dinwiddie * http://blog.gdinwiddie.com
                            Software Development http://www.idiacomputing.com
                            Consultant and Coach http://www.agilemaryland.org
                            ----------------------------------------------------------------------
                          • JackM
                            Try to break your stories down further so they re smaller. When you get good at this then your burndowns will burndown from day 1 Hope this helps Jack
                            Message 13 of 15 , May 9, 2012
                            • 0 Attachment
                              Try to break your stories down further so they're smaller. When you get good at this then your burndowns will burndown from day 1

                              Hope this helps
                              Jack
                              www.agilebuddy.com
                              blog.agilebuddy.com

                              --- In scrumdevelopment@yahoogroups.com, "simonmorris7809" <mozrat@...> wrote:
                              >
                              > Hello all,
                              >
                              > I mainly wanted to introduce myself to the group as a newbie but also ask a quick question.
                              >
                              > I've been following the group for a while and I find the insights really valuable. Thanks for the time you spend on this community.
                              >
                              > So - in our sprints we consistently start slow and have a big finish. You can see our latest burndown chart here.
                              >
                              > https://plus.google.com/105300838558555602864/posts/LMfs4LmkEzJ
                              >
                              > This isn't necessarily a problem as we ship features on time and with the correct quality, but it is always a slight feeling of panic as we drift away from the "Ideal" line.
                              >
                              > I don't really want to push the group to start stronger as we consistently deliver successfully and putting more effort into the first couple of days would just serve to make the chart prettier.
                              >
                              > Does anyone else see this as a warning sign - maybe I should just stop checking the burndown chart in the first half of the sprint :-)
                              >
                              > Thanks
                              >
                            • Charles Bradley - Scrum Coach CSP CSM PSM
                              Simon, Welcome to the list! Background:  I have coached 3 full scale Scrum transitions where the
                              Message 14 of 15 , May 10, 2012
                              • 0 Attachment
                                Simon,

                                Welcome to the list!

                                <all my opinion>

                                <bare with me for a little background />
                                Background:  I have coached 3 full scale Scrum transitions where the team had the following characteristics:
                                • team doing something markedly "other than Scrum" prior to my arrival and struggling
                                • team had zero formal Scrum training and org strongly preferred coaching rather than formal training
                                  • I have been able to convince almost all of them to send at least their PO's and SM's to formal training right around the time I leave.
                                • team doing full on Scrum by the time I left (3-6 months later)
                                Obviously, doing 3 of these particular types(I call them "bootstrapping gigs") of engagements does not make me the foremost expert in coaching these kinds of teams or anything, but the results, given that they had no formal Scrum training, are pretty darned excellent, IMO.  But I'm very biased.  :-)

                                When determining what to focus on in coaching the early sprints, I generally do a contextual approach, focusing on what I, as coach, think is the most important thing for the team to get better at.  In other words, "conditions on the ground" generally indicate to me where to focus next.  In later sprints, I turn this "improvement focus" over to the Scrum team itself.
                                </background over>

                                So, if I'm ignoring what all else I would normally focus on, and instead only focus in on your burndown line, with no other context, here is the summary of my observations:
                                • IMO, your (actual) line looks very typical for a story point burndown for a relatively new to intermediate team.
                                • Questions I would ask
                                  1. Can you tell me a little more about the story that was added mid Sprint?
                                  2. If you have people whose area of focus is testing, what are they usually doing for the first several days of the Sprint?
                                  3. It's generally good practice to get story sizes small, to a few days.  Would this be possible for your team?
                                  4. The (so-called)ideal line, esp from 4/17-4/20, looks weird to me.  Did a small story get dropped in that period?
                                  5. It looks like there was a large amount of closure(story completion) late in the sprint.  Did the people focused on closing these stories (testing, PO, whoever) feel hurried, rushed, or nervous that not enough testing was done?
                                  6. It looks like a small story did not get completed by end of sprint.  Normally that's not a big deal -- how did the team take this? (from a morale/emotion standpoint)
                                  7. You mention a slight feeling of panic when the ideal deviates from the actual line.  In your view, does this help the team to "dig in" and focus on "getting to done"?
                                When I'm doing these full scale transitions(whether the teams have almost zero training or not), and I'm analyzing the Sprint Burndown, here is the order in which I generally focus for improvement(as it relates to the Sprint Burndown):

                                (I generally start these new teams off with an ideal task hour burndown, assuming 5-6 ideal hours per day.  Later, I might encourage experimentation with other types of burndowns.  For these new teams, I have a strong person preference for burndowns instead of burnups, and a very strong preference for hand drawing burndowns on a "big visible chart" vs. using a tool.)

                                A.  Get good at "getting to Done" for the forecasted items, and don't be afraid to drop/add items.
                                • By about Sprint 4, I'd like to see the team be finishing 90+% of the stories that they "accepted into" the sprint (i.e. what they forecast that would be completed), *with* a high confidence that near zero defects will be discovered. 
                                  • This also assumes that a healthy definition of done has been created, whether that be explicitly or implicitly.  I push very hard for this level of quality to remain at this level(or higher) indefinitely. 
                                • As such, I tell the teams that the Sprint burndown probably won't help us much in the early sprints -- the only time it is likely to help us is mid sprint to help indicate that we have taken on way too much for this sprint and it might encourage us to drop some stories.
                                B.  Mild retrospection on Sprint Burndowns
                                • After step A, I encourage the team to begin analyzing their burndown for things like:
                                  • Are we greatly under/over estimating the number of task hours for a sprint?
                                  • How often are we having to add/drop items?
                                  • Are there times in the sprint when we feel panicked?
                                  • Are there times in the sprint when a person is working way hard or way little?
                                • I encourage the team to experiment with possibly ways to improve the above.
                                C.  Encourage smoothing out of the Sprint flow by getting stories smaller and/or increasing test automation
                                • Generally, these teams experience a situation where the testers(testing focused people) are pretty bored the first few days and pretty panicked the last few days, a holdover from waterfall in my view. 
                                • It is at this time that I usually introduce *another* burndown, burning down by story points (I make sure both of them are displayed).  At this point, with a small amount of creative license, you can usually show that their story point burndown looks literally like a waterfall! 
                                • I encourage the team to try to smooth out this flow a little by one or both of:
                                  • Testers begin automating tests early in the sprint, so that they can have a test suite built up for stories before the stories are even "delivered for testing." (This is not always possible for various reasons)
                                  • Splitting stories smaller so that a couple of stories are delivered for testing earlier in the iteration.
                                D.  Encourage experimentation with Sprint Backlog tasks, different task units, different burndowns
                                • At this point I encourage the team to experiment with different techniques, but caution them that
                                  • a) Let's try to maintain our now smoother flow, and
                                  • b) Let's not forget that changing too many variables(techniques) at once might decrease the transparency on the effects of these changes
                                If there is a "micro managing" tone to the above for these teams, it is *intentional* during this bootstrapping period.  By about the time the team gets to Step D, I begin moving from "micro managing" to "laissez faire", and then I eventually "sneak off into the sunset," looking back only once, to see the team fully engaged in self organizing themselves. 

                                For non-bootstrapping teams, I use totally different leadership styles!  In coaching terms, I take different "coaching stances" based on what the team needs.

                                </all my opinion>

                                -------
                                Charles Bradley
                                http://www.ScrumCrazy.com




                                From: Simon Morris <mozrat@...>
                                To: scrumdevelopment@yahoogroups.com
                                Sent: Friday, April 20, 2012 11:34 AM
                                Subject: [scrumdevelopment] Burndown charts and late finishers



                                Hello all,

                                I mainly wanted to introduce myself to the group as a newbie but also ask a quick question.

                                I've been following the group for a while and I find the insights really valuable. Thanks for the time you spend on this community.

                                So - in our sprints we consistently start slow and have a big finish. You can see our latest burndown chart here.


                                This isn't necessarily a problem as we ship features on time and with the correct quality, but it is always a slight feeling of panic as we drift away from the "Ideal" line.

                                I don't really want to push the group to start stronger as we consistently deliver successfully and putting more effort into the first couple of days would just serve to make the chart prettier.

                                Does anyone else see this as a warning sign - maybe I should just stop checking the burndown chart in the first half of the sprint :-)

                                Thanks

                                Simon






                              • Simon Morris
                                Hello, When I first looked at the graph, I thought your actuals were actually ... Sorry for having left this thread for so long - have been away for a while.
                                Message 15 of 15 , May 22, 2012
                                • 0 Attachment
                                  Hello,

                                  When I first looked at the graph, I thought your actuals were actually *too* close to the ideal. The line *should* actually go up before it goes down, because no amount of analysis will ever result in knowing all the tasks and the effort required in advance.

                                  But then I realized your burndown is showing the completion of stories, not tasks! So that left me pondering, do most you you all burn down stories within a sprint, or do you burn down tasks?


                                  Sorry for having left this thread for so long - have been away for a while.

                                  I'm also interested in the stories and tasks questions. It's worth noting that the Scrum team I am a member of is fairly immature in experience of the methodology but we're keen on improving.

                                  We only use stories but I'd be interested in using tasks if we can see a clear benefit.

                                  The way I've always done it is, after the team commits to stories in the planning meeting, they then brainstorm all the tasks and estimate them in hours. Summing all the hours then provides a rough cross-check of the committment (i.e. if the task hours sum to about 50% - 70% of the total working hours available, you're probably within the ballpark. If the total hours exceed 70% of the available time, then the team is probably over-committed). 


                                  We use a system of:

                                  * Working out our total committed rate over the length of the sprint.
                                  * Reserving 20% of that capacity for admin, pruning, overrun
                                  * Committing to stories in order of priority until we get to the remaining 80%

                                  So - we use a padding system of 20% and its encouraging that others use the same method.

                                  Thanks for the response.

                                  Simon  
                                Your message has been successfully submitted and would be delivered to recipients shortly.