Step 5: Estimation & release grouping

This chapter describes the fifth step in the framework, detailing how to estimate the previously detailed requirements and how to group them into meaningful releases.

When doing agile estimates, there are many techniques out there. There are even movements that advocate having no estimates at all. We recommend to start with the practices laid out in this chapter to have a solid foundation and evolve estimation practices from there.

Estimation is a learning process. Over time, we will naturally alter the estimation procedures based on our learnings and individual organizational needs.

Note that in “Step 3: Prioritization”, a relative estimation already has been done. At this stage, estimation gets more accurate, as all necessary steps of work have been collected and a more thorough understanding has been gained during user story mapping.

For the estimation process, we recommend using these good practices:

• Estimation takes time. There are faster, but more inaccurate techniques, like T-shirt sizing (Estimating all items into “buckets” of T-Shirt-Sizes, like S, M, L, XL) or more accurate but also more time consuming techniques, like planning poker[1]. If we have to estimate large amounts, start with faster but more inaccurate techniques. If we want to plan more accurately, i.e. for the next 2 months, we should use more precise techniques.
• Estimations are always made with the information currently at hand. As information changes and new things are learned, estimations that were made in the past may not be accurate anymore. That means, estimations decay over time. This requires us to estimate on a regular basis. Doing estimates as a one-off session at the beginning of a project is highly risky and will lead to many problems down the road.
• Estimations always include uncertainty. The bigger the estimation is, the higher the uncertainty. That’s why it has proven effective to use scales that are not linear when estimating (e.g. planning poker uses scales like 1, 2, 3, 5, 8, 13, 20 and so on, which reflect the increasing level of uncertainty)
• Numeric vs. non-numeric estimations: Both types work. But having some sort of numeric estimations allows us to do neat things like adding up the estimates of multiple work items that form a release. This usually makes working within larger organizations much easier. That’s why we recommend using numeric estimation methods (like planning poker) or transferring the results of non-numeric estimations back to numeric ones: E.g. by assigning a number to each T-Shirt-Size – i.e. S = 1, M=5, L = 13, XL = 40).
• Agree to estimation references to reach alignment with estimations across teams: It has been a proven practice to set a reference-work-item for each estimation size. So after some time, our teams should have a reference story for each estimation size. I.e. if planning poker is used, there should be a reference story for all common sizes, like 1,2,3,5,8,13. For each new work item, teams then compare the new item to the references to come up with an estimate. Having estimation references reduces estimation variance, which in turn makes estimations more reliable. With multiple teams, it is recommended to align these references between teams.

That said, we recommend doing the estimation process in the following order:

1. Once all currently known requirements are collected by breaking down the opportunities/improvements, start estimating all of them with a fast, but inaccurate method to give rough estimates. (Like T-Shirt-Sizing)
2. Reorder items and releases as necessary: Once estimations are done, usually the priority changes, as some items are so much effort, that it does not make sense to develop them, whereas others are so easy to implement, that they are prioritized higher.
3. If things are too large, break them down into smaller items. (Also known as user story splitting[2])
4. For the most important items, use a more precise estimation technique to achieve a more precise basis for short-term-planning. (Like planning poker)
5. Repeat this continuously so we always have a precise estimate on the work for the next 3 months, a rougher estimate on the work forth the next 3-6 months and a rough estimate for everything beyond 6 months.

When all requirement elicitation and estimation is done, start grouping them into releases that will enable meaningful functionality to end users. Note, that this has to be aligned with the development methodology and release management plans for the product.[3]

Smaller, more frequent releases are preferred, as learning and continuous improvement with real feedback can happen more often, which increases product quality.

It’s important to view this from a customer point of view. It’s of no use if the database is created, but the user’s data is not yet stored in it. So we always have to make sure to slice releases in a way, that there is meaningful functionality visible for end users with each release. Also take into account all outlined dependencies and restructure the requirements or the releases accordingly.

The following image illustrates the grouping into releases. Usually releases group one or multiple opportunities/improvements, but sometimes it’s not possible and they have to be split across multiple releases. In the example below, “Improvement Y” can only be partly completed in release 2 and thus was split. Note that the splitting takes into account all dependencies, so all interdependent parts are in one release, enabling full functionality to be delivered to users.)

As we can see, in the schematic above, our Release 2 is marked as “MVP”. The Minimum viable product (or MVP in short) defines the earliest stage at which we can release our product to our customers to validate our product goals. (First principle of the agile manifesto: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”[4])  It is highly important, that this MVP is released as early as possible, as the learnings gathered from real user feedback usually have a high impact on product development. Releasing an MVP early massively reduces our risk to lose a lot of money by developing something the customers don’t need/want. So when slicing up the first releases, the product manager/owner marks the point where the product incorporates valuable features that can be released as MVP. The MVP might only be released to a very small user group or in a small geographic region, but it should be as early as possible to learn from actual customer/market feedback.

[1] Planning Poker: Usually done within Scrum teams. For each item, everyone picks a hidden numeric card and then all cards are revealed, compared and discussed in depth to come up with an agreed upon estimation. For more info see:  https://www.mountaingoatsoftware.com/agile/planning-poker

[2] See https://www.humanizingwork.com/the-humanizing-work-guide-to-splitting-user-stories/ for more info on user story splitting

[3] Note that this grouping happens from a user’s point of view, to outline what group of work items would form a useful improvement for the customer. Also note, that releasing is not the same as deployment. You can deploy the current version of a product to your servers, without actually releasing it to customers.

[4] https://agilemanifesto.org/principles.html