Title: Agile Estimating and Planning

Q: Features of a good planning process
A: ◆ Reducing risk
◆ Reducing uncertainty
◆ Supporting better decision making
◆ Establishing trust
◆ Conveying information

Q: Features of agile planning
A: ◆ It ss focused more on the planning than on the plan
◆ Encourages change
◆ Results in plans that are easily changed
◆ Is spread throughout the project

Q: Reasons that activity-based planning leads to schedule overruns
A: ◆ Activities don’t finish early.
◆ Lateness is passed down the schedule.
◆ Activities are not independent.

Q: The main ways in which agile teams work
A: ◆ Work as one team
◆ Work in short iterations
◆ Deliver something each iteration
◆ Focus on business priorities
◆ Inspect and adapt

The planning onion

Conditions of satisfaction drive both release and iteration planning

Q: 3 levels of planning
A: Release planning
Iteration planning
Daily planning

The process of estimating duration

Q: Story points
A: Story points are a unit of measure for expressing the overall size of a user story, feature, or other piece of work. When we estimate with story points, we assign a point value to each item. The raw values we assign are unimportant. What matters are the relative values. A story that is assigned a two should be twice as much as a story that is assigned a one. It should also be two-thirds of a story that is estimated as three story points.

Q: Approaches to estimate story points
A: The first approach is to select a story that you expect to be one of the smallest stories you’ll work with and say that story is estimated at one story point.
The second approach is instead to select a story that seems somewhat medium and give it a number somewhere in the middle of the range you expect to use.

Q: Velocity
A: Velocity is a measure of a team’s rate of progress. It is calculated by summing the number of story points assigned to each user story that the team completed during the iterations.

Q: Ideal time vs. elapsed time on a software project
A: On a software project, ideal time differs from elapsed time not because of timeouts, incomplete passes, and injuries, but because of the natural overhead we experience every day. On any given day, in addition to working on the planned activities of a project, a team member may spend time answering email, making a support call to a vendor, interviewing a candidate for the open analyst position, and attending two meetings.

Q: Assumptions for estimating ideal days
A: ◆ The story being estimated is the only thing you’ll work on.
◆ Everything you need will be on hand when you start.
◆ There will be no interruptions.

Q: The purpose of re-estimating
A: Whenever the team feels one or more stories are misestimated relative to other stories, re-estimate as few stories as possible to bring the relative estimates back in line. Use reestimating as a learning experience for estimating future user stories.

Q: The key points in favor of estimating in story points
A: ◆ Story points help drive cross-functional behavior.
◆ Story-point estimates do not decay.
◆ Story points are a pure measure of size.
◆ Estimating in story points typically is faster.
◆ My ideal days are not your ideal days.

Q: The key points in favor of estimating in ideal days
A: ◆ Ideal days are easier to explain outside the team.
◆ Ideal days are easier to estimate at first.

Q: Factors in prioritization
A: 1. The financial value of having the features.
2. The cost of developing (and perhaps supporting) the new features.
3. The amount and significance of learning and new knowledge created by developing the features.
4. The amount of risk removed by developing the features.

Q: Ways to evaluate a cash flow stream
A: Net present value
Internal rate or return (return on investment)
Payback period
Discounted payback period

The Kano model of customer satisfaction

Q: Factors to consider when prioritizing features
A: 1. The amount and significance of learning and new knowledge created by developing the features.
2. The amount of risk removed by developing the features.
3. The financial value of having the features.
4. The cost of developing (and perhaps supporting) the new features.

Q: A release plan
A: A release plan is a high-level plan that covers a period longer than an iteration. For most teams a release occurs every three to six months.
A release plan does not have to describe exactly what will be worked on during each iteration. In fact, that level of detail is rarely needed. For most projects it is quite adequate to identify the stories that will be worked on in the first couple of iterations, leaving the remaining stories to be prioritized into specific iterations later.
Once a release plan has been created, it is not left hanging on a wall to rot. It is usually updated at the start of each iteration.

Q: Iteration planning
A: An iteration plan looks in more detail at the specific work of a single iteration. Rather than the three-to-nine month horizon of a typical release plan, the iteration plan looks out no further than a single iteration. The fairly large user stories of a release plan are decomposed into tasks on the iteration plan. Each task is estimated in terms of the number of ideal hours the task will take to complete.

Q: Factors in selecting an iteration length
A: ◆ The length of the release being worked on
◆ The amount of uncertainty
◆ The ease of getting feedback
◆ How long priorities can remain unchanged
◆ Willingness to go without outside feedback
◆ The overhead of iterating
◆ How soon a feeling of urgency is established

Q: Planning a release is estimating the velocity options
A: ◆ Use historical values.
◆ Run an iteration.
◆ Make a forecast.

Q: Requirements of planning a multiple team project
A: 1. Establishing a common basis for estimates.
2. Adding detail to their user stories sooner.
3. Performing lookahead planning.
4. Incorporating feeding buffers into the plan.

Q: A release burndown bar chart
A: A release burndown chart shows the number of story points or ideal days remaining in the project as of the start of each iteration.

Q: A parking-lot chart
A: A parking-lot chart is useful for presenting a high-level view of a team’s progress toward implementing the various themes planned in a project.

Q: A task board
A: A task board—which is often a whiteboard, corkboard, or just a designated space on a wall—helps a team organize and visualize their work. The columns of a task board are labeled, and team members move task cards through the columns as work progresses.

Q: An iteration burndown chart
A: An iteration burndown chart is similar to a release burndown chart but is used to track only the work of the current iteration. It graphs the number of hours remaining on the vertical axis and the days of the iteration on the horizontal axis.