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

RE: [scrumdevelopment] need help planning a sprint planning session

Expand Messages
  • Mike Cohn
    Hi Tony- Question A If you have a sprint that is just a fairly random collection of things then I’ve used sprint goals like the following: a) Add
    Message 1 of 2 , Apr 20, 2003

      Hi Tony—


      Question A

      If you have a sprint that is just a fairly random collection of things then Ive used sprint goals like the following:


      a)       Add in the features wed hoped to get in 1.0 but missed.

      b)       Add the features necessary for the product to be usable by customer XYZ.

      c)       Add enough new features to justify a new GA (Generally Available) release

      d)       <empty>


      Yes, its OK to leave out the sprint goal when you have a truly random set of tasks. However, there was probably something that led the team to prioritize as they did. Usually its getting the product ready for a specific customer who needs some new feature or such.  Ive also used (but never liked) sprint goals like Get enough of XYZ done this sprint that we can finish all the ABC next sprint.


      Question B

      First, dont update MS Project as you go. The process needs to be very fluid and the last thing you need is someone saying, But wait, five minutes you said that was in. You were right to get rid of it. (Nothing against MS Project—it makes nice pictures but its not the right Scrum tracking tool.) Just use Excel and put an X in a column when youre done to indicate the tasks/stories the team signed up for.  


      Your approach (of meeting with each developer) probably wont take you too far astray as you get a team started with Scrum. The key is that they need to own the selection of sprint backlog. If youre too involved it feels like a plan-driven process and they wont own the backlog: We only signed up for that because we felt pressure from you. We knew you wanted that much done this sprint so we tried but we didnt think wed make it. Its definitely OK to help a team more on the first sprint or two but you soon want to have them do it all themselves. You can do that by helping them figure it out.


      One thing they can do is if  the project has any true specialists then have them identify the work they can complete. I consider a true specialist someone like a DBA who is great with Oracle but doesnt know Java. Try to avoid having true specialists but some (many?) projects need some—DBAs, tech writers, Human Factors Engineers, etc. Note that some of these are a bit different—the DBA can do her job and there probably isnt anyone else who can fill in for her; however, on most teams theres usually someone else who can do a credible job of tech writing besides the tech writer; perhaps the real tech writer cleans it up but at least theres someone to help. Anyway, for true specialists like DBAs have them identify what they can get done.


      Next, let the team figure out how deep in the backlog they can go. Ive coached teams through that this way:


      Project on a screen the list of backlog items (I use Excel or defect tracking systems typically). The list is sorted in approximately the exact order. Were not sure that #16 is more urgent than #17 but its definitely more urgent than #30. Point 4 items (or so) down the list and ask the team if they can get that far. (Be sure youre asking at a level theres no doubt about.) Theyll say yes. Point at about #8. Maybe they have to think now. (This all depends on the size of your backlog tasks / stories.) Thats good—have them talk about how theyd do it. The dialog will be something like:


      Well, I could probably do 1 through 3. Andrew or James could do 4-5 and the other could do 6-8. That seems reasonable.

      Sure, 6-8 arent hard. We could get that far.


      Now, theyve started planning. Ask, Is that the right amount then or should we bite off a bit more?


      Within another round or two of this the team will be very engaged in the discussion and making tentative plans about you do this and Ill do that and so on. None of these specific plans matter except that they are scenarios under which the team can envision success with the amount of work they choose. If you get everyone to this point then you just sit back and listen. As a ScrumMaster your role is to ask some questions and keep the confidence of the team up but you cant really force them to self-organize. If this approach doesnt work (Ive had two teams that didnt engage quickly after doing this) then just sit in the room with them offering your complete support but stressing that its up to them to figure out how much they can get done in the sprint. Id equate to the interviewing technique of when you ask someone a question just sit silently, even if it gets uncomfortable, until they answer it. The team will eventually answer it.







      -----Original Message-----
      From: Tony Homer [mailto:tony_homer@...]
      Thursday, April 17, 2003 6:18 PM
      To: 'scrumdevelopment@yahoogroups.com'
      Subject: RE: [scrumdevelopment] need help planning a sprint planning session


      Thanks for the fantastic response, Mike.  I appreciate the ideas about how to manage having a hydra for a Product Owner, but that actually wasn't the issue.  I'll try to clarify.


      For the first Sprint Planning Session we did not include the Product Owner because that role had yet to be filled (it is NOW filled), but the product backlog had been clearly prioritized in an access database by a group of individuals collectively approximating a Product Owner (bugs and enhancements 1-N).  We had trouble with the mechanics of the meeting in two main areas: 


      A. How do you define a Sprint goal?  The examples in the literature are clear, but don't seem to apply to our project.  Our project is a data collection and verification system that is in a development/production mode.  Many of the tasks in the product backlog are business requirements that didn't make it into the initial release.  However, they are prioritized in a somewhat heterogeneous fashion, so when you select the set to be completed in the Sprint it's hard to say what the Sprint Goal is other than: complete the 27 things we said we'd do.  For example, here are the top 3 prioritized tasks from the Sprint we are just wrapping up (these are unedited):


      1. There is a need to have 3 output files created:  1.  Output from Data Inquiry match Job or a store list job - when a new match job is created.  2.  Retail Sync Inquiries- For the most current match made for each record- a new match job is not created.  3.  General Inquiry (I.e. Closed store) - a match job is not created.      I have detailed user specs for all three and today we receive this information using a predetermined list of either client #'s or TDLinx codes and the requested information is appende directely to our master list excel sheet.  I will supply specs upon request
      2. When attempting to import a file into access that was  exported from a match job in MSW, the found that fields are not formatted to work in access; each field has an = and " " (double quotes) around it.  In order to use the file in access all of these extra characters need to be removed from the file.  We still need to maintain the integrity of each field and reflect the actual field lenghts including all lead zeroes in each field.
      3. It appears that "Post Match" which I'm not exactly sure is the Bulk Data Importer, bypasses the Opinion Usage buesiness rules for Opinions.  We need to make sure that the Post Match Utility conforms with the DSW Business Rules set up for opinions.


      B. How do you select the tasks for inclusion *as a team*?  When we met for our abortive first Sprint Planning Session, we had the product backlog prioritized in excel with very little advance estimation.  We started at the top and very haltingly individual team members indicated whether or not they felt a particular task belonged to them.  Our project coordinator was trying to update MS Project as we proceeded.  It was a mess.  Everyone felt unclear as to what to do and it felt really unwieldy so we wrote it off as a miss.  Some things have changed since then: for example I've moved us away from MS Project and everyone has had more exposure to Scrum.


      I ended up building the Sprint Plan by meeting with each individual developer.  I did this on an individual basis with the developers by calculating how many hours of work we could do during the sprint (8 hours * X days = Y hours), picking tasks based on priority and keeping a running tally of work.  I asked each developer to scale their selection set according to what they felt comfortable with in terms of estimation confidence. However, *I* assigned tasks to individuals for estimation and then had them select tasks from their assigned set, rather than letting the team choose their own tasks in a more chaotic fashion.  I believe in the Scrum book, Mike Beedle talks about developers owning code forever.  This is basically how I assigned tasks: if an enhancement is being requested on a particular piece of the application, we know who the owner is already, so that task goes into that individual's bucket.



      Finally, thanks for your great example.  I thought everything you described should get done in one big session, but it sounds like it makes more sense to review the Product Backlog with the Product Owner and the team to define high-priority backlog, then follow-up with the team to build a Sprint Plan, then publish the Sprint Plan to the Product Owner.  I guess your example helps me to see where we need to go, but the issues I describe above are more about how to get there...



      -----Original Message-----
      From: Mike Cohn [mailto:mike@...]
      Sent: Thursday, April 17, 2003 4:10 PM
      To: scrumdevelopment@yahoogroups.com
      Subject: RE: [scrumdevelopment] need help planning a sprint planning session


      I'm not sure I'll be on the right track with my answer because you say you "sat around in the conference room and got frustrated" but you don't say why. What got frustrating? I'm going to guess it was a lack of agreement on exactly what the top priorities are. That seems to be the most common problem with working a multi-headed Product Owner.  The others on the committee may be feeling resentful that you are selecting one of their peers as the primary product owner. Or, there could be a dozen or more things like that going on.


      If you are working with a group of product owner you need to make sure the group represented by each gets something in approximately every sprint. Otherwise you'll end up with a few resentful groups. You may have a few groups mature enough to recognize that they are not the top priority and they'll be reasonable to work with. With other groups you'll have to appease them by putting of their desires in even if they wouldn't otherwise quite make the cut. I'm not talking about putting in low priority stuff but when stacked purely from 1-100 in priority you might decide you can do stories (requirements/tasks) 1-10. But when you look those are all from Group A. So, take out stories 9 and 10 and add 14 and 17, from two other groups. Sounds like you're not doing the biggest user-valued functionality-and in that sprint you aren't-but by fostering a more cooperative effort over the multi-sprint period you are maximizing client value.


      I don't use any special tools. I tend to use Excel or a defect tracker for stories (rather than cards). I ask the Product Owner(s) to come to the meeting with them in rough priority order. (not 1-100 but very high to very low, etc.) The Product Owner throws out an initial sprint goal, "This release lets ....." which is based on how she prioritized the stories-she must have had something in her mind as she sorted them, rephrase that a bit and you probably have a sprint goal.


      At the meeting the Product Owner explains the story and keeps going down the list until I'm pretty sure we've got enough. We then excuse everyone but the technical team and do a wideband Delphi estimate of each story. We then pull out as many as we think fit in a sprint and review our estimates of just those. Then we present it back to the Product Owner (team) and make sure we didn't pick all the lowest of the "Very Highs" or something randomly bad like that. (The sprint goal helps avoid this, too.)


      Good luck. Let me know if you have any more questions. OR-if I completely went with the wrong assumption about why your team got frustrated, let me know why they did and I'll address the question better.




      -----Original Message-----
      From: Tony Homer [mailto:tony_homer@...]
      Sent: Wednesday, April 16, 2003 9:45 AM
      To: 'scrumdevelopment@yahoogroups.com'
      Subject: [scrumdevelopment] need help planning a sprint planning session


      I'm new to the group and relatively new to scrum.  I've read the scrum book (although I need to reread parts of it to internalize the information) and reviewed information on some of the scrum websites (controlchaos, mountaingoatsoftaware).


      I've been attempting a phased adoption of scrum on my project in my traditional project management shop.  The project team consists of 5.5 developers (one is split between 2 projects), 2 DBAs, and 2 QA specialists, so we are at the upper boundary of size for a scrum team.  We have configuration managment and administrative support available but not dedicated to the team.  The project had been managed in a very directed fashion in the past (MS project, 3+ months iterations, weekly status meetings, overtime to "stay on track", etc.), but the project manager/project lead was let go a few months ago.  I am one of the developers, acting as scrummaster and team leader.  I have little to no project management experience (but this should be good because I'm basically tabula rasa, right?  No bad habits to unlearn? Right?). 


      The product owner is essentially a committee of individuals at our client (actually a sibling organization) who meet to prioritize backlog.  There is a primary point of contact who I am trying to build into a product owner.


      We've been holding daily scrums for about 6 weeks now and we are wrapping up our first Sprint.  We attempted to hold a sprint planning session for the first sprint, but it was not productive.  Basically, we sat around in the conference room and got frustrated.  I had to cancel the meeting and pursue a different strategy for selecting the tasks for the sprint.


      Here's how we selected the tasks for the last Sprint:

      1. I individually reviewed product backlog (actually a prioritized access-based buglog containing bugs and enhancements) and distributed a set of tasks to the development team to gather planning estimates.

      2. I individually met with each developer on the team to determine what they thought they could get done in the next sprint.

      3. I published the results.


      This is obviously non-optimal. 


      The scrum book and the various scrum websites make it sound so easy to conduct a sprint planning session: just get everyone who cares together and decide what you are going to do in the next 30 days.  When I tried to do this, the team was not successful.  Maybe we had the wrong tools.


      Can anyone share the details of how to conduct a sprint planning session?  What are the prerequisites?  What tools do you use to facilitate the session?  How do you define a Sprint goal?



      Tony Homer




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

      Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.


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

      Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

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

      Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
    Your message has been successfully submitted and would be delivered to recipients shortly.