Determining the size of an Agile project can be a bit of a paradox. On one hand, planning poker is a remarkable tool, yet when there are hundreds of stories on the backlog it's too time consuming to determine the size of a project. That's where affinity estimating joins the planning party.
Even with Agile, you need to spend some time and effort to determine the project size. I've created the following guidelines for estimating Agile projects.
- Product owner provides clear vision about product to people who will give estimates. A product vision board will help convey the big picture.
- If needed, product owner could create story board to show the product's workflow.
- Product owner may already have high-level product backlog or can work with team to create one. A user story workshop is one way to create stories with the team.
- Team will use affinity estimating to estimate a large backlog (affinity estimates work best with 20 or more stories). Teams that have been together a long time and are familiar with product will provide better estimates.
- The goal of affinity estimating is to provide a rough estimate of a project's size. Will the project take 3 months, 6 months, a year?
- Team reviews features and asks, do these features need new infrastructure or can they work with our existing framework? In most cases, new architectures will increase risk and size of project.
- Estimates larger than a month should be broken down into smaller stories. The estimation error on a month is too large to risk.
I suggest using rolling wave planning and creating a product roadmap of only three to six months. Anything longer and you are creating WIP. You'll lose the advantage of replacing projects with features the customers really want. And that's what Agile portfolio management is all about.