Starting a Scrum project in a corporate environment, you often find yourself on the "green field," facing roughly defined requirements with a clear and fixed deadline. You are rarely in a position to choose the development team, or the number of teams. So the question is whether the given team will manage to meet the deadline and deliver high-quality software on time. Luckily, having chosen Scrum, you are, after a relatively short period, able to picture the future and visualize the potential of your team.
1. The green field
Once on the green field, we visualize the target and the distance to it as a path on the geographical map. Next we choose the most adequate vehicle. Sometimes it's a solar plane, another time a sailing boat, or, as illustrated here, a car. We keep this metaphor from the first through the last sprint.
2. Initial rough product backlog estimation
As mentioned above, the product backlog is, at the very beginning, defined as a set of roughly defined epics, features, and -- if you are lucky -- even some nicely defined stories. The team estimates the amount of work using Planning Poker. In this initial estimation session, I like to use t-shirt sizes (XXS, XS, S, M, L, XL, XXL) rather than the numbered poker cards. I have the feeling that this makes it easier for everybody to stop thinking in days and rather start thinking in story points.
Once all the items in the product backlog (PBL) are estimated, we pick a batch of XS, M, and XL stories (one or two per category) and do what we would do in the second sprint planning session -- try to nail down tasks and estimate them in hours. This way we can extrapolate the total amount of work for the whole PBL.
Now we know the distance on the map from Bern to Torino. If the vision of the product or service you are developing is still not very clear, and especially if the product owner is not sure that the PBL is covering all the needed functionalities, you might consider introducing a correction "uncertainty factor" on the final estimate.
3. Release planning
Having estimated the PBL, we are ready to make the first version of our release plan. Together with the product owner, we define high-level aims and place them, according to their business priority, as the stops on our path. Think of vertical slicing while defining the release "stepping stones." Check and recheck your PBL for completeness. If some features are not clear yet, the product owner should try to put a placeholder in for them and formulate them roughly. For the features that are going to be required and included, any estimate done by the team is better than no estimate.
Having split the PBL in vertical slices, we assign each PBL item to the segment on the road. Now we can calculate the length of each segment -- the amount of work for each release. Our map now looks like this:
Our ideal burn-down looks like this:
4. Iterations and progress
As we start sprinting, we gather information on the velocity of our car. This information we display from sprint to sprint on our sprint "TomTom" device -- our sprint review dashboard. An example illustrates our dashboard after four sprints, which corresponds to the delivery of Release 2 functionalities.
On the upper graphics, apart from IDEAL and DONE lines, you can see the lines corresponding to the future "burn-down potential" of the team, calculated with three different velocity values. The value 0.8 is taken as the lowest value ("tough path"), the value 0.9 is taken as the value from the actual sprint, and, finally, the violet line corresponds to the most optimistic value of 1.1 ("happy path"). From the graphics we can see that even with the lowest velocity, the team still meets the goal. This is in no way a commitment! It is just a snapshot in time and the best guess in the actual moment.
We redo all the graphics from sprint to sprint based on the actual state of the product backlog and show the dashboard at the sprint review meeting.
Note that the IDEAL line also changes from sprint to sprint, since new stories get formulated as a result of PBL grooming. During the grooming, we estimate new stories and replace initial rough epic or feature estimates with estimates of the actual stories that are formulated under the features and epics. Keep in mind the importance of sticking to the initially selected reference story.
You might also get new requirements that will affect the graphics. In general, the better the quality of your PBL, the better the statistics.
During our reviews, we like to emphasize that our map supports "Street View," meaning that anybody is welcome to drop in and listen during our daily Scrums and become informed about the "zoom-in" status of the actual sprint (as long as he or she respects the rules of the daily Scrum!).