This may or may not be helpful to some people but i just wanted to do a walk-through of a typical sprint planning 'process' I just tried using with the current team I'm on. We have me (programmer/scrum master), a tester, a business person, a requirement writer, and various 'specialists' giving us hours here and there (mainframe, webservices, and database). I'm basically acting as scrum master and sometimes as 'product owner' in many regards. (generally the product owner situations i end up in are ones where the technical team must prioritize and the customer team does not care one way or another on the priority at that low of level)
- I fire up Breeze (it's basically like a Webex or typical desktop sharing utility)
- I get everyone connected so they can see my desktop.
- I launch scrumworks (our chosen tool for distributed scrum) - maybe you use a spreadsheet or story cards or whatever.
- I load up our PRD (product requirements document) for a particular project (usually to add to our existing 'evergreen' product)
- I read the first "Detailed Business Requirement" outloud or ask the team to read it on the their own. (usually they have their own copy of the word document.
- Create a backlog item in scrumworks that represents that requirement.
- Have a timeboxed discussion (i usually don't set a time limit because people already have a tough time speaking up, but if it goes on too long in silence i start asking specific people questions... like 'if you had this software in front of you and you were going to validate this requirement, what would you do?)
- Ask the QA people what they would plan on testing. Maybe ask the business what QA might have missed or vice versa.
- break down the feature/backlog item into tasks. In scrumworks i usually denote each task with a functional group and then the task. for example the backlog item might be "User can save their settings". The tasks would maybe be "Dev: build aspx page layout", "Dev: build model classes", "Dba: setup tables and sprocs", "QA: write test scripts", "QA: execute test scripts" "BIZ: user acceptance test"
- Once the tasks have been decomposed and estimated in 'ideal hours' i total that up and assign the backlog item that as the 'ideal hour' size. Yes most tasks can run concurrently but the point is getting a general 'complexity' or 'size' to it so i figure there's a bit of shwag to it anyhow.
- Ask the team if they have enough room to commit to this backlog item taking into consideration all the functional groups needed to get to "Done" on it.
- Add it to the Sprint or skip it depending on 10
- Repeat steps 5-12 as needed until no more backlog items can be committed to.
- Some requirements may need consolidated into one backlog item (for example if a requirement is Dependant on another, I put them together as one and see if it makes sense... sometimes then we split them back out if it makes sense to split them in a different way by 'features' instead of by layers of software)
- Revisit estimates on the next reasonable amount of backlog items or estimate any un-estimated backlog items in the product backlog.