Iteration planning

Question

We are currently trying some new ways of planning out iteration. Earlier the leaddev decided what features are in an iteration an who (which pair) is going to work on it. Aditionally he made a first guess on how long the feature will take to be implemented. Now we have a team-discussion on each feature during the iteration planning and the team decides how long we will need to implement the task. Then we decide who is going to implement it. This takes quiet a long time.

How do you do your iteration planning (planning game)?

Answer 1

First, if you want a better control of the time you spend doing things, use time boxing. In Scrum, every thing is time boxed and I think it's a good thing. From my experience, 4 hours is a decent duration for the iteration planning meeting of a 2 week iteration. Then, the planning meeting is usually divided in two parts that are time boxed to 2 hours. The first one is used to select the items from the backlog that will be implemented. The second one is used to breakdown the selected features into tasks and create the Spring backlog.

For the first part of the planning meeting:

• Estimate stories with a relative unit (Story Points, T-shirt size, etc). Use Planning Poker to estimate the stories, it's a pretty effective technique.
• Pick stories up to your velocity (how much work you did last time in story points). Select the stories with the highest value/effort ratio.

For the second part of the planning meeting:

• Break down the stories into tasks. Estimate these tasks in hours (a task shouldn't exceed 16h). With this level of detail the whole team understands exactly what to do, and anyone can potentially pick a task from the list.
• Don't decide upfront who is going to implement what, let the team auto organize. Tasks on the sprint backlog are never assigned; rather, tasks are signed up for by the team members as needed, according to the set priority and the team member skills.

Answer 2

We break down each of the big stories into tasks so that each can be easier to estimate as big stories tend to have many smaller steps that as a team there is more confidence in being able to estimate those. A big story could be setting up a section of a site,e.g. about the company or showing the products the company sells, or getting some new component up and running, e.g. search functionality or product registration. In contrast the tasks are usually things that can be done in 2 days or less so that we don't have a big black hole and cards can move from column to column during the sprint.

Once a list of tasks for a sprint have been identified, an Excel spreadsheet is e-mailed to everyone in the team to add their estimates and send back to the Scrum Master. The Scrum Master takes an average of all the estimates in order to get a gauge of the hours needed for a task. If there is some wide discrepancy then this may be discussed with those at each extreme for why they believe something will take so long.

Answer 3

Traditionally, we take the next highest priority story cards from our backlog / release plan (with high level "story point" estimates"), break them down into tasks, have people estimate them, and write these down on a sheet of paper. Whatever pair is next available can pick which task they would like. This usually doesn't take too long (one week iterations).

Recently I've been transitioning my team towards a Kanban system, where the emphasis is on flow instead iterations. High level estimates are still important for release planning, but otherwise we just ensure that the stories are prioritized properly. People pull stories from state to state, and any roadblocks are brought up either at the morning standup or throughout the day (if it is something that would prevent work).

If you're working on a project that lends itself well to somewhat continuous deployment (examples would include a website or auto-updating end user software, as opposed to something that has an arduous install process), you could consider not doing too much estimating. It may still be necessary for some ROI things (i.e. will the work spent on this outweigh the benefit?), but by eliminating the estimates and releasing things when they are ready you can get into more of a flow. This actually gets away from iterations, but it means more time is spent on getting work done in a continuous process than planning, subdividing tasks, etc. A kanban system would be useful for this. This is the technique we currently use for our maintenance / FastTrack releases - when we've finished enough bug fixes / enhancements, we ship. Small releases are valued much higher than large releases.

Answer 4

Try to keep your length of the iteration fixed, so that you know how much time you have for implementation. Fix your resources and calculate their available time and make sure you have enough resources to cover the entire duration. Base don available resources their expertise and the priorities of the task assign the resources to the tasks. Keep adding the task until there are enough resources for the iteration