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:
That said, we recommend doing the estimation process in the following order:
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.