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

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

Expand Messages
  • 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 1 of 3 , Oct 5, 2005

      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.