Defining the Agile Planning Sprint - Feature Estimation

In previous posts, I've written about Why and How to Estimate in Agile, How to Conduct a Story Sizing Meeting, and on Five Key Agile Practices to Support Architects.

In this post, I'm going to get a little bit more detailed in what I call an Agile Planning Sprint. This post will cover the process on providing Agile Estimates. In other other posts, I will describe other tasks/deliverables of Agile Planning.

The purpose of Estimation as part of the Agile Planning Sprint is simple - take newly defined features, solution them into scenarios, break scenarios down to story stubs, and estimate the stories. The purpose of this cycle is to give the business stakeholders a first estimate of costs and tradeoffs on what to include or not include in the feature's scope. It also gives technical leads a quick process to develop solutions and consider the complexity points.

Here is a one week sprint that can be leveraged to estimate features:

• Day 1, Business Stakeholder Session - At a meeting of stakeholders (including product owners, and senior technologists), three agendas are scheduled:
• Feature Backlog Review - The Program Manager reviews status on the top features in the agile planning backlog and reviews status.
• Solution Review - All Features that were estimated over the last agile planning sprint are reviewed with stakeholders. These are given "go/no-go" votes and "in/out of scope" on specific feature details. Features given a "Go" will go into the next task in Agile Planning - Requirements Gathering and Story Writing - which will be covered in another posts.
• New Feature Prioritization - The sponsor of a new feature presents the feature definition and its business value. At the end of this meeting, new features are voted on and the feature backlog is prioritized with the new features.


• Day 2, Agile Planning Session - The technology / program management team reviews the feature backlog for new features and progress on old features. Team leaders (often tech leads, business analysts, and QA leads - but that depends on your organization) commit to features estimation.


• Day 3-4 - Team leaders work on tasks. For features in agile planning, Team Leaders develop multiple scenarios (options) to fulfill the requirements. At least one scenario should represent a "minimal feature set".


• Day 5 - Architectural Review Session - Team leaders present their story stubs, estimates, and assumptions to architectural and program leads. For each feature, the architecture team makes the following decisions:
• Ready for Solution Review - Architects review the feature and decide the stubs and estimates developed by the Team Leaders fully represent the requirements and technical dependencies of the feature. The team decides which of the Scenarios should be presented at the Feature Review, and which can be left behind. This team also considers what feature elements should be reviewed for "in/out of scope".
• Additional Estimation Required - The architect team can force a feature in for a second round of planning if the story stubs don't represent an end to end feature definition, if the estimates are challenged and need review in more detail, if dependencies on other teams need to be considered, or if additional scenarios need to be developed.

In this process I'm stretching the definition of "sprint" and deliberately selecting a fast one-week cadence. The stretch is because a feature's planning might not achieve 'done' (as in estimation complete) at the end of a week either because its complexity requires more planning, or because it does not pass the architecture review. This is by design; complex features that require multiple planning sprints become feedback to the stakeholder - maybe you're feature is too complex. It also forces quick estimates and solutions since many features will not make it to the next task in Agile Planning - requirements gathering and story writing.