Agile Planning: it’s not an oxymoron.
On Tuesday, April 15, our Teamstart webinar series will answer your questions about Agile Planning. Whether you’re just getting started with Agile or consider yourself an expert, join us to get and give good Q+A. We'll talk about making and keeping commitments, using tracking and metrics to predict delivery, and planning levels with time horizons.
Here are a few questions from past Agile Planning webinars:
- How does the product owner role fit into Agile Planning?
- Are there guidelines for setting up good planning estimates?
- If the team is not able to complete a story before the iteration ends, or if a critical change is requested, how do we respond?
From an Agile Planning perspective these are related questions. Let’s take a look at the answers to see why.
1. How does the product owner role fit into Agile planning?
Answer: A product owner initiates and translates the product roadmap into a manageable product backlog. He or she participates in daily standups and manages the product dashboard. The product owner communicates with internal teams and the product manager, to understand the features and requirements and support the release planning and sprint planning exercises. It’s also the product owner’s job to allow the team to manage itself and understand Agile estimation approaches.
2. Are there guidelines for setting up good planning estimates?
Answer: The principal guideline when estimating user story size is to employ a comparative approach. For example, rather than estimating in absolute terms, such as hours or days, you use abstract "story points" to compare the sizes of work items with past work the team has completed. Using an example the team is already familiar with helps you establish a baseline. By contrast, task size should be estimated in hours, since a task should be small enough that it doesn’t span more than a working day (about six hours.)
The estimation of stories done in abstract values happens continuously, and well before iteration planning; whereas task estimation is done once during the iteration planning meeting, immediately before the team votes to commit to the proposed work.
3. If the team is not able to complete a story before the iteration ends, or if a critical change is requested, how do we respond?
Answer: When the scope of a user story becomes larger -- either because you underestimated its scope or because a change request comes in -- you should finish the current iteration as planned, and re-plan the remaining iterations in the release. In a situation where the team still has a fixed delivery date, you must work with the business to determine what other committed-to features or functions may be sacrificed to continue to work within the timebox limits. Teams should review burndown charts daily, so that you can spot problems early and mitigate them. When it’s necessary to re-estimate and re-prioritize features, you should signal to the business and stakeholders as soon as possible.
I bet you have at least three questions about Agile! Learn more about Agile Planning. Check out our Agile Webinar Series.