Webinar Recap: Agile Estimating and Planning Best Practices
Three Agile Planning Horizons
Agile estimating and planning involves three “horizons” :
- Release Plan, around 2-6 months
- Iteration Plan, 2-4 weeks
- Daily Plan, every day
Below is a brief overview of these horizons, as explained in our latest Watermark Learning webinar: Agile Estimating and Planning Best Practices. The webinar is now available on demand and it includes numerous practical examples and visual aids.
Horizon 1: Agile Release Plan
The release plan answers the question: “When will you be done (or partially done)?” The release is accomplished through a series of iterations.
Release planning involves the following 5 actions: (1) selecting themes and user stories, (2) estimating user stories, (3) selecting iteration length, (4) estimating or forecasting the team’s velocity, and (5) selecting a release date.
1. Select Themes and User Stories
Themes are collections of related user stories (also called Minimally Marketable Features). Once themes have been selected, user stories that compose the themes are selected from the product backlog and prioritized.
A useful way to prioritize these user stories is through the MoSCoW rules.
Must have, features that are fundamental to the system
Should have, features that are important but for which workarounds exist
Could have, can be left out if time runs out for the release
Won’t have, desired, but won’t be included in the release
Best Practice: During release planning, use themes and the MoSCoW rules to provide agility during the release cycle.
2. Estimate User Stories
In order to estimate user stories, consider using one of the following user story estimation techniques:
The first technique is story points, which are a measure of relative size. Story points can be numbers or other size measures (e.g. t-shirt sizes). Story points estimate the “bigness” of a user story relative to other stories.
The second technique is ideal days, which refer to the amount of time a story takes to develop with no interruptions. This is an estimate of effort rather than relative size.
Best Practice: Refine your user story estimates as uncertainty is reduced.
3. Select an Iteration Length
The release is composed of a series of iterations (also known as sprints when using Scrum) which are typically 2-4 weeks long.
4. Estimate Velocity
Velocity is a measure of the team’s rate of progress (e.g. the number of story points / ideal days completed during an iteration). This can be an observed velocity or a forecasted velocity based on the team’s capacity.
Watch the full presentation to see examples of how to forecast a team’s velocity.
Best Practice: Use velocity to predict work and team capacity to confirm it during release and iteration planning.
5. Select Release Date
Horizon 2: Agile Iteration Plan
During the Iteration Planning Meeting, user stories are selected for an iteration based on the release plan, development priority, and size. The team discusses each story and breaks each story down into the tasks that need to be done to complete it. Then tasks are estimated using ideal days or hours. Task estimates are done collaboratively with the whole team.
Ready vs. Done
Note that stories need to be “ready” in order to be implemented in an iteration. “Ready” means that the acceptance criteria have been defined and are well understood so that the team can break the story down into tasks. Ready also means that the story is small enough for a team to deliver between a number of them within an iteration, typically 4-10.
Stories are not ready if it takes a long time in planning for the team to understand the user story and break it into tasks, or if a lot of additional tasks are identified within an iteration that were not originally expected, or if the story isn’t completed within the iteration, etc.
Keep in mind the difference between “ready” and “done.” Ready refers to whether the story can be completed within an iteration. Meanwhile, Done means “complete as mutually agreed to by all parties and conforming to an organizations standards, conventions, and guidelines.” (Ken Schwaber). Each team needs to develop their definition of done with their stakeholders.
Best Practice: Define clear criteria for when a story is “Ready” for iteration planning and when a story is “Done.”
Horizon 3: Daily Plan
The Daily Stand Up (or Daily Scrum when using Scrum) consists of a brief (no more than 15 minute) daily meeting. Each team member responds to 3 questions:
- What did I do yesterday?
- What do I plan to do today?
- What impediments are in my way?
Track the progress using a Team Board and a Burndown Chart. These are “big visible charts” or information radiators that are usually hung on a wall so that anyone can see the status of the project at a glance.
For more in-depth examples, check out the full webinar on demand (requires free Watermark Learning membership).
Looking for Agile skills training? Check out our Agile Planning and Estimating class!
Marsha is a senior instructor and consultant for Watermark Learning, and has more than thirty years of experience in the software, technology, telecommunications, and Internet business sectors. She has numerous accomplishments in Agile methods, project management, business analysis, software development, methodology development, process improvement, and courseware development and training.
She is a Certified Scrum Master and Professional, a Certified BA Professional, and a Certified PM Professional. She is also a contributor to the IIBA’s Agile Extension to the BABOK, and the agile perspective in version 3.0 of the BABOK.
Great webinar, but I still have questions over the participation of Project Managers and their relationship to ScrumMasters.
It seems to me that applying traditional PM practices to a Scrum project is outside the normal scope of Scrum activities. Doesn’t that indicate that the organization is not truly ready to adopt Scrum? Doesn’t traditional PM drive projects to a more waterfall (plan and control) model?
While a traditional PM may adopt the role of a ScrumMaster, aren’t they really two different roles, with different skill sets and objectives?
I’m not saying that this shouldn’t be done; only that it should be recognized for what it is.
Excellent webinar. Looking forward to the rest of the series!
I have a question. Traditionally in the waterfall methodology, the review or inspection technique is a formal way of checking for requirements quality and removing requirements defects before future work is performed on the requirements. I’ve reviewed the Agile Extention to the BABOK, where it says verification of requirements usually is done through direct stakeholder interaction with the team as the software is developed.
Based on experience, what is the best way and timing for reviewing the quality of the requirements in agile? It doesn’t seem cost effective that you’d pair the most formal inspection process with agile, where detailed and formal documentation is not the epmphasis.
Hi Tom and Ryan, thanks for your questions.
Marsha has addressed most of the unanswered questions from her webinar in a separate blog post.
Comments have been closed. Post additional questions on our dedicated Q&A post at:
Comments are closed.