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

Re: [scrumdevelopment] Burndown Charts and Earned Value

Expand Messages
  • Mike Cohn
    That s the paper. Thanks for sharing it. Mike Cohn Author: Agile Estimating and Planning User Stories Applied www.mountaingoatsoftware.com ... That s the
    Message 1 of 19 , Sep 7, 2006
    • 0 Attachment
      That's the paper. Thanks for sharing it.
      Mike Cohn
      Author:
        Agile Estimating and Planning
        User Stories Applied
      www.mountaingoatsoftware.com


      On Sep 7, 2006, at 2:00 PM, Pato Jutard wrote:


      Thanks Hubert, thanks Mike.

       

      Hubert, of course Tobias is a great trainer and he taught us Burndown charts, but I’m the bad pupil J

       

      Mike, I looked for the Paper you mentioned, I think I find it so I’ll share it with the list:

       

      http://www.solutionsiq.com/PDF/Sulaiman-AgileEVM.pdf

       

      Cheers,

       

      Patricio

      www.threemelons.com

       


      De: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] En nombre de Mike Cohn
      Enviado el: Jueves, 07 de Septiembre de 2006 04:18 p.m.
      Para: scrumdevelopment@yahoogroups.com
      CC: Brent Barton
      Asunto: Re: [scrumdevelopment] Burndown Charts and Earned Value

       

      Brent Barton and some colleagues from Solutions IQ presented a great paper on Earned Value at the Agile 2006 conference. I don't know if a copy of it is online anywhere. Maybe Brent can enlighten us.

      Congratulations on taking your game studio to Scrum. Other game developers are having tremendous success with Scrum as well.

      Regards,

      Mike Cohn

      Author:

        Agile Estimating and Planning

        User Stories Applied

      www.mountaingoatsoftware.com



       

      On Sep 7, 2006, at 12:05 PM, Pato Jutard wrote:



       

      I’m starting to implement Scrum in Three Melons, a game studio in Argentina after becoming CSM with the excellent course given by Tobias Mayer over here.

       

      We are going great, but now I want to make progress visible and make some velocity-based estimations, anticipate deviations, have a clear picture of remaining work, know when the team performance is going down and need further motivation, etc

       

      For this purposes I know some people is working with Burndown charts. Am I correct?

       

      I have this resource:http://alistair.cockburn.us/index.php/Earned-value_and_burn_charts

       

      Can someone guide me in this aspect?

       

      What are you people using?

       

      Can you provide any advice or any reference to material that treats this subject?

       

      Thank you very much!

       

       

      Patricio Jutard
      Technology Orchestrator- Three Melons
      Argentina: +54 11 4878-0130 int. 201
      New York: +1   212 202-1458 ext. 201
      pato@threemelons.com

      www.threemelons.com

       



    • Brent Barton
      Hi Patricio, This is it. Let us know if you need more implementation details. Also, Tamara Sulaiman and Thomas Blackburn can help. Cheers, Brent
      Message 2 of 19 , Sep 7, 2006
      • 0 Attachment
        Hi Patricio,
         
        This is it.  Let us know if you need more implementation details.  Also, Tamara Sulaiman and Thomas Blackburn can help.
         
        Cheers,
        Brent


        From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Pato Jutard
        Sent: Thursday, September 07, 2006 1:01 PM
        To: scrumdevelopment@yahoogroups.com
        Subject: RE: [scrumdevelopment] Burndown Charts and Earned Value

        Thanks Hubert, thanks Mike.

        Hubert, of course Tobias is a great trainer and he taught us Burndown charts, but I’m the bad pupil J

        Mike, I looked for the Paper you mentioned, I think I find it so I’ll share it with the list:

        http://www.solution siq.com/PDF/ Sulaiman- AgileEVM. pdf

        Cheers,

        Patricio

        www.threemelons. com


        De: scrumdevelopment@ yahoogroups. com [mailto:scrumdevelo pment@yahoogroup s.com] En nombre de Mike Cohn
        Enviado el: Jueves, 07 de Septiembre de 2006 04:18 p.m.
        Para: scrumdevelopment@ yahoogroups. com
        CC: Brent Barton
        Asunto: Re: [scrumdevelopment] Burndown Charts and Earned Value

        Brent Barton and some colleagues from Solutions IQ presented a great paper on Earned Value at the Agile 2006 conference. I don't know if a copy of it is online anywhere. Maybe Brent can enlighten us.

        Congratulations on taking your game studio to Scrum. Other game developers are having tremendous success with Scrum as well.

        Regards,

        Mike Cohn

        Author:

          Agile Estimating and Planning

          User Stories Applied

        www.mountaingoatsof tware.com



        On Sep 7, 2006, at 12:05 PM, Pato Jutard wrote:



        I’m starting to implement Scrum in Three Melons, a game studio inArgentina after becoming CSM with the excellent course given by Tobias Mayer over here.

        We are going great, but now I want to make progress visible and make some velocity-based estimations, anticipate deviations, have a clear picture of remaining work, know when the team performance is going down and need further motivation, etc

        For this purposes I know some people is working with Burndown charts. Am I correct?

        I have this resource:http://alistair. cockburn. us/index. php/Earned- value_and_ burn_charts

        Can someone guide me in this aspect?

        What are you people using?

        Can you provide any advice or any reference to material that treats this subject?

        Thank you very much!

        Patricio Jutard
        Technology Orchestrator- Three Melons
        Argentina: +54 11 4878-0130 int. 201
        New York: +1   212 202-1458 ext. 201
        pato@threemelons. com

        www.threemelons. com

      • Mark Levison
        Thanks to everyone for the replies on this thread - this has done a great deal to improve my thinking. Cheers Mark Levison ... Blog:
        Message 3 of 19 , Sep 8, 2006
        • 0 Attachment
          Thanks to everyone for the replies on this thread - this has done a great deal to improve my thinking.

          Cheers
          Mark Levison
          ----------------------------------------------------------------------
          Blog: http://www.notesfromatooluser.com/
        • Dave Hostick
          Hi All, I ve been scrumming for three years now at three different companies (don t ask)... I agree entirely with Mark. As soon as the story goes into the
          Message 4 of 19 , Sep 9, 2006
          • 0 Attachment
            Hi All,

            I've been scrumming for three years now at three different companies
            (don't ask)...

            I agree entirely with Mark. As soon as the story goes into the
            backlog, it gets a rough 'order of magnitude' estimate for the Product
            Owner to prioritise and put in the right area for the product road map
            - then getting back to the customer with a reasonable prediction for
            when the requirement (story) will be released. Anyone can supply this
            estimate - even the Product Owner (based on similar stories), so don't
            think you're putting on the developers - at this stage it's not that
            important to be exact.

            As this story gets nearer the sprint, the details of the requirement
            are matured and you might want another 'guestimate'. During sprint
            planning, you still won't get it exactly right; so, when in the
            sprint, the story is continually re-estimated - this is essential for
            the burn down to be as realistic as possible.

            This is how I work and I hope it clarifies things,

            Dave

            --- In scrumdevelopment@yahoogroups.com, "Mark Levison" <mlevison@...>
            wrote:
            >
            > On 9/7/06, Hubert Smits <hubert.smits@...> wrote:
            > >
            > > Hi Mark,
            > >
            > > Estimate every story when it goes onto the backlog. Few reasons to do
            > > this: it gives the product owner information which she can use to
            prioritize
            > > (geeeeee, this is a biggie and it has little value, let me give it
            a low
            > > priority), and it gives an indicator of the total effort to
            complete the
            > > product with all the features
            > >
            >
            > Thanks for the feedback Hubert - doesn't that suggest that I might be
            > getting the team together to estimate every few days (especially in the
            > early phase of the project). In addition I was concerned about the
            quality
            > of one off estimates. My thinking if we estimate 4-5 stories at once
            we're
            > likely to have a better sense of their relative costs.
            >
            > Mark
            > ----------------------------------------------------------------------
            > Blog: http://www.notesfromatooluser.com/
            >
          • Dave Hostick
            Correction - I mean I agree entirely with Hubert not Mark... not that it really matters... just in case though ;-) Dave ... to do ... in the
            Message 5 of 19 , Sep 9, 2006
            • 0 Attachment
              Correction - I mean "I agree entirely with Hubert" not Mark... not
              that it really matters... just in case though ;-)

              Dave

              --- In scrumdevelopment@yahoogroups.com, "Dave Hostick" <scrum@...> wrote:
              >
              > Hi All,
              >
              > I've been scrumming for three years now at three different companies
              > (don't ask)...
              >
              > I agree entirely with Mark. As soon as the story goes into the
              > backlog, it gets a rough 'order of magnitude' estimate for the Product
              > Owner to prioritise and put in the right area for the product road map
              > - then getting back to the customer with a reasonable prediction for
              > when the requirement (story) will be released. Anyone can supply this
              > estimate - even the Product Owner (based on similar stories), so don't
              > think you're putting on the developers - at this stage it's not that
              > important to be exact.
              >
              > As this story gets nearer the sprint, the details of the requirement
              > are matured and you might want another 'guestimate'. During sprint
              > planning, you still won't get it exactly right; so, when in the
              > sprint, the story is continually re-estimated - this is essential for
              > the burn down to be as realistic as possible.
              >
              > This is how I work and I hope it clarifies things,
              >
              > Dave
              >
              > --- In scrumdevelopment@yahoogroups.com, "Mark Levison" <mlevison@>
              > wrote:
              > >
              > > On 9/7/06, Hubert Smits <hubert.smits@> wrote:
              > > >
              > > > Hi Mark,
              > > >
              > > > Estimate every story when it goes onto the backlog. Few reasons
              to do
              > > > this: it gives the product owner information which she can use to
              > prioritize
              > > > (geeeeee, this is a biggie and it has little value, let me give it
              > a low
              > > > priority), and it gives an indicator of the total effort to
              > complete the
              > > > product with all the features
              > > >
              > >
              > > Thanks for the feedback Hubert - doesn't that suggest that I might be
              > > getting the team together to estimate every few days (especially
              in the
              > > early phase of the project). In addition I was concerned about the
              > quality
              > > of one off estimates. My thinking if we estimate 4-5 stories at once
              > we're
              > > likely to have a better sense of their relative costs.
              > >
              > > Mark
              > > ----------------------------------------------------------------------
              > > Blog: http://www.notesfromatooluser.com/
              > >
              >
            • Arrowood, Paul (ELS-STL)
              we re slightly modified from this (in how we interpreted something from Mike Cohn s book). When we add stories, we give them an attribute called Front
              Message 6 of 19 , Sep 12, 2006
              • 0 Attachment
                we're slightly modified from this (in how we interpreted something from Mike Cohn's book).   When we add stories, we give them an attribute called Front Burner, Back Burner or Refrigerator (priorities).
                 
                Refrigerator = we don't even bother with the ROM estimate
                Front Burner = no brainer, of course must estimate
                Back Burner = need to estimate as quickly as you can, because these guys would be next (if we were able to address more stories)


                From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Dave Hostick
                Sent: Saturday, September 09, 2006 3:58 AM
                To: scrumdevelopment@yahoogroups.com
                Subject: [scrumdevelopment] Re: When to estimate the product backlog?

                Hi All,

                I've been scrumming for three years now at three different companies
                (don't ask)...

                I agree entirely with Mark. As soon as the story goes into the
                backlog, it gets a rough 'order of magnitude' estimate for the Product
                Owner to prioritise and put in the right area for the product road map
                - then getting back to the customer with a reasonable prediction for
                when the requirement (story) will be released. Anyone can supply this
                estimate - even the Product Owner (based on similar stories), so don't
                think you're putting on the developers - at this stage it's not that
                important to be exact.

                As this story gets nearer the sprint, the details of the requirement
                are matured and you might want another 'guestimate' . During sprint
                planning, you still won't get it exactly right; so, when in the
                sprint, the story is continually re-estimated - this is essential for
                the burn down to be as realistic as possible.

                This is how I work and I hope it clarifies things,

                Dave

                --- In scrumdevelopment@ yahoogroups. com, "Mark Levison" <mlevison@.. .>
                wrote:
                >
                > On 9/7/06, Hubert Smits <hubert.smits@ ...> wrote:
                > >
                > > Hi Mark,
                > >
                > > Estimate every story when it goes onto the backlog. Few reasons to do
                > > this: it gives the product owner information which she can use to
                prioritize
                > > (geeeeee, this is a biggie and it has little value, let me give it
                a low
                > > priority), and it gives an indicator of the total effort to
                complete the
                > > product with all the features
                > >
                >
                > Thanks for the feedback Hubert - doesn't that suggest that I might be
                > getting the team together to estimate every few days (especially in the
                > early phase of the project). In addition I was concerned about the
                quality
                > of one off estimates. My thinking if we estimate 4-5 stories at once
                we're
                > likely to have a better sense of their relative costs.
                >
                > Mark
                > ------------ --------- --------- --------- --------- --------- -
                > Blog: http://www.notesfro matooluser. com/
                >

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