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

Re: [scrumdevelopment] What makes for good sprint planning?

Expand Messages
  • Mike Cohn
    Hi David-- I teach teams to pursue what I call ³commitment-driven sprint planning.² The way this works is that the product owner and team collaboratively
    Message 1 of 3 , Oct 4, 2005
    • 0 Attachment
      Re: [scrumdevelopment] What makes for good sprint planning? Hi David--
      I teach teams to pursue what I call “commitment-driven sprint planning.” The way this works is that the product owner and team collaboratively decide on the most important one product backlog item to develop. They then decompose that into tasks. The team then asks itself, “Can we commit to this developing this backlog item?” On the first item it’s pretty likely to be an easy yes. They then select a second, decompose it, and ask themselves the same question. During this I prefer that teams not assign specific tasks to specific individuals. The right time for an individual to sign up for a task is right when starting it, not weeks ahead of time. Of course, everyone has a general idea of who is likely to do what during the sprint but that’s different. The team continues this way until someone says “I’m full; I can’t do this additional item.” At that point the sprint is full. (There may be opportunities to find another small item that doesn’t affect the full person, etc. but you get the idea by now, I suspect.)

      This happens with all developers in the room. It will indeed likely take 4 hours (for a two-week sprint generally for me). After some experience it will often be closer to 2-1/2 to 3 hours. During this time the team is not doing just sprint planning. They are also doing design. They are talking about whether it’s best to implement this feature in the middle tier or the database, whether this language or that is better for the client part, whether objects for that feature should be cached, etc. This type of design needs to occur with everyone present, not with everyone doing separate thinking and bringing estimates into the room. That would be a huge mistake. If the team focuses during the meeting, they won’t take 4 hours. They take four hours when the team jokes around, stalls too much, and loses focus. I’m not opposed to a little of that, but when the team is focused it doesn’t always take 4 hours to plan 2 week sprints.

      BTW, I find that a good average is 3 hours for 2 week sprints. Teams with 4-week sprints do it in 4-5 hours. So, 4-week sprints have less overhead and that’s good, right? Not really—after some point teams just give up and stop estimating/planning with sufficient care and accuracy. If it takes 3 hours to plan the next 2 weeks, it  should take more than twice that to plan the next 4 since we know even less about the second two weeks. Teams, however, spend less on the second two weeks because they’re so anxious to get out of the meeting.

      By the way, not to push it unduly but I’ve just finished a book on “Agile Estimating and Planning.” It should be out around 10/24. It has a long chapter (20 or more pages) on sprint planning and addresses these points in much more detail. You can see info on the book here: http://www.mountaingoatsoftware.com/agileplanning  and it is available already at Amazon (and I assume other places).

      Regards,
      Mike Cohn
      Author:
          Agile Estimating and Planning
          User Stories Applied for Agile Software Development
      www.mountaingoatsoftware.com



      On 10/4/05 2:36 PM, "David Roberts" <droberts@...> wrote:

      I’d like to see if anyone has any suggestions, customizations, etc… to sprint planning that they’ve found necessary to make it work; specifically in regard to the team self-tasking and committing to the highest priority work.
       
      I’ve seen it done a couple ways:
      1. The team goes through the priorities, describing each backlog item and individuals volunteer to take items. Initial estimate performed by technical leaders, the team as a whole, or individual members are used to determine how much of the product backlog can be done. The team details tasking offline.
      2. Similar to situation 1, but the team sits in a 4+ hour meeting and defines all the tasking during that meeting.

      I’ve seen other slight variations as far as initial estimates, use of stories, etc… What I’d like to discover is how the tasking part comes into play. I’ve heard two arguments:
      1. If the team tasks separately, tasking is often inconsistent.
      2. If the team tasks together, they dread going to long 4 hour meetings.

      I tend to think that if the team is in a common area, they can task outside the meeting but still be communicating. I’d really appreciate any feedback on this.
       
      - David


      To Post a message, send it to:   scrumdevelopment@...
      To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...

        

       
       SPONSORED LINKS
                
        Scrum <http://groups.yahoo.com/gads?t=ms&k=Scrum&w1=Scrum&c=1&s=11&.sig=KvDTKhw7ncC9XbB25jdApQ>          
       
       

      YAHOO! GROUPS LINKS


       



    • Kiran Thakkar
      David, We ran into issue of dragging planning meeting more than 6-7 hours because team tasks together. We were horrible in estimating in our first two sprints.
      Message 2 of 3 , Oct 5, 2005
      • 0 Attachment

        David,

        We ran into issue of dragging planning meeting more than 6-7 hours because team tasks together. We were horrible in estimating in our first two sprints. And after that here is what we tried.

        1. We have one hours meeting with tech lead/product owner, functional manager (resource Manager) and Scrum Master (project manager) to go over priorities and requirements for next sprint. Outcome of this pre-planning meeting:
          1. Priority list of feature functions
          2. Two-three line descriptions of feature functions
          3. Tech leads high-level estimates.
          4. Potential team members
        2. We passed outcome of pre-planning meeting to the team. Team will have about a week time to under stand the requirement and come up with the questions for product owner.
        3. We have two ½ days sprint planning meeting
        4. On 1st half day sprint planning we go over the requirements, come up with sprint goals and development team get a chance to ask any questions they have to product owners.
        5. On 2nd half-day sprint planning meeting team works on creating sprint backlog with detail tasks and estimates.
         
        BTW, My role is ScrumMaster (Project Manager) on these sprints. I run 3-4 sprints in parallel as a Scrum Master.

         

        Does this make sense?

         

        Thanks,

        Kiran Thakkar

        Sr. Project Manager (Siemens Medical Solutions)



        David Roberts <droberts@...> wrote:

        I’d like to see if anyone has any suggestions, customizations, etc… to sprint planning that they’ve found necessary to make it work; specifically in regard to the team self-tasking and committing to the highest priority work.

         

        I’ve seen it done a couple ways:

        1. The team goes through the priorities, describing each backlog item and individuals volunteer to take items. Initial estimate performed by technical leaders, the team as a whole, or individual members are used to determine how much of the product backlog can be done. The team details tasking offline.
        2. Similar to situation 1, but the team sits in a 4+ hour meeting and defines all the tasking during that meeting.

         

        I’ve seen other slight variations as far as initial estimates, use of stories, etc… What I’d like to discover is how the tasking part comes into play. I’ve heard two arguments:

        1. If the team tasks separately, tasking is often inconsistent.
        2. If the team tasks together, they dread going to long 4 hour meetings.

         

        I tend to think that if the team is in a common area, they can task outside the meeting but still be communicating. I’d really appreciate any feedback on this.

         

        - David




        Yahoo! for Good
        Click here to donate to the Hurricane Katrina relief effort.

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