Contents
You’re a Scrum Team Now
No matter how it turned out, at this point your team has completed its first sprint! I hope you have already groomed your stories for the next sprint, unless you do that during your Planning Ceremony. As far as I am concerned, you are now officially a Scrum Team. Easy, right?! Now do it all again. And again. And again…
At the risk of going overboard with this advice, I’m going to suggest one more time that you not change the FuSca™ process or scale up to releases until you attain 100% acceptance in a sprint, and preferably do a couple more at high rates. Make sure you really understand how to ride the bike down the sidewalk before you take off the training wheels, or take it onto a busy street!
You won’t do most of the actions covered in this “Prepare…” section every sprint, and teams with self-discipline will almost never do them. Your tracker will need a little attention, detailed in the relevant step set. Some digital trackers need you to manually close the sprint, for example, and you have to clear the cards from a paper tracker. Doing some other clean-up will speed the Planning Ceremony, but that is only necessary when stories or bugs are left undone.
If that continues happening after six sprints, tracking actual hours for each task can help a team immensely in its drive to improve. Ideally the results can be presented at the Retro, but often people wait until the last minute to update the tracker, so that is impractical unless the tracker does it for you. As soon as possible thereafter, the Facilitator can run these calculations and send them to the team for consideration in the next Planning Ceremony.
The good news is, it will take you a lot less time to do all this than it does to read this section!
Split Incomplete Stories and Defects
No matter the reason a story (or standalone defect) is left undone at the end of a sprint, you need to do something with it. My preference is to just move it into the backlog or next sprint, whichever the Team Guide prefers, and deleting the completed tasks. This is in line with both minimizing documentation and honoring the principle, “Working software is the primary measure of progress.”
However, if you are using a digital tracker that calculates acceptance rates for you, you will need a record of the incomplete work. (Otherwise the rate would always be 100%!) The process of “splitting” creates a copy of the story in the backlog or next sprint while leaving the original in the old Sprint Plan to maintain its history. Completed tasks stay in the original story, which is left in the “In-Progress” or similar state, and any incomplete tasks are moved to the copy. The original retains the history of the work, while the new one is treated like any other new story.
Some digital trackers have a function to create the copy and automatically move incomplete tasks. They also place the new story in the next sprint by default. The TG might want it placed in the backlog instead, which I prefer, for rank-ordering against new stories: At times new customer requirements are higher priority than the remaining work. The tracker may allow you to make that scheduling change in the split tool.
Regardless of how the incomplete work is handled, it may need to be groomed for changes resulting from the completed work, both in the body of the “new” story and the task list. The story might need new Acceptance Criteria and related changes to make it reflect the remaining work. If the story was completed but rejected by the customer, the new version definitely needs massaging. At the very least, in digital trackers you’ll need to change the task fields for the estimates to match the to-dos. By definition, the task owner has been re-estimating throughout the sprint, so the current to-do is the new estimate. Just double-check them with the task owners during the Planning Ceremony.
At the other extreme, a story that wasn’t even started may be good to go as it is, but take a minute to verify that with the team during a Grooming Session. The reasons may be related to the story itself. Perhaps something learned over the course of the sprint will suggest changes in the story, such as a new solution raised by a similar problem in an accepted story.
Note cards in a paper tracker can just be moved to the preferred location and completed tasks removed. Those who feel the need can create a copy for the old sprint’s set that references the moved original rather than copying all of the information.
By the way, the splitting function in a digital tracker is also useful in two other cases. One is when you are grooming and decide a story is too large for one sprint. When you aren’t sure, go ahead and task out the story. Perhaps by doing that, and definitely by the time you assign and estimate the tasks, the answer will become clear. You can use the split method to break out a portion for a later sprint, if needed. The preference, again, is to split it into complete, testable pieces of functionality. You can also use this approach to create a shared story. Create all of the tasks for both teams; split the story, moving the other team’s tasks to the copy; and put the copy in the other team’s backlog.
⇒ Steps: Prepare for the New Sprint
Improve Estimation
Compare Task Hours
An Actual Problem
Tracking the number of actual hours used in completing stories is irrelevant to a mature Scrum team and rife with risk for abuse. Specifically, managers who came up in a era of tracking labor hours as a mistaken way of tracking productivity may focus on that instead of delivery of value. To those teams able to hit 100% delivery without using actuals, I tip one of my many hats. (I’m bald; I can’t change my hair anymore, but I can still change my hats!)
For those who struggle, I have found the analysis of actuals to estimates on a story by story basis—not putting any individual on the spot—an outstanding shortcut to getting to 100% delivery. Team members get hard evidence they are (usually) being too optimistic, plus a way to measure their improvement sprint to sprint.
Some teams decide to track actuals from the start until they hit that Performance Standard. Certainly you should consider it if not headed in the right direction after three sprints, and almost certainly do it if still falling short after six. For comparison, note that every team I have coached directly hit the standard by their fourth sprint.
To implement this technique, everyone needs to loosely keep track of how much time they spend on each task. There are free apps you can use. I used to jot time ranges on a sticky note on my desk and add them up at the end of the day. When you adjust your to-dos, also add that day’s time to the previous Actual totals. A digital tracker will probably have a field for this, though your tool admin may have to unhide it. For paper trackers, add it to the bottom of the task note, in a place distinct from your estimate and to-dos. You could list these three figures vertically, for example.
Digital trackers with the individual capacity function will also likely summarize estimates, to-dos, and actuals at a story level. However, incomplete stories present a problem: the actuals do not reflect all the work to be done. For this reason, I go the extra step of exporting the information and setting up a spreadsheet to add the actuals to the to-dos for a better comparison point. A tracker also probably won’t give you percentages, which allow a more accurate sprint-to-sprint comparison. And of course, teams using a paper tracker have to do something else to get the calculations.
Fill Out a Spreadsheet
To address those issues if needed, export from your digital tracker the following fields into the FuSca “Sprint Analysis” spreadsheet—the export format might be called “CSV”[1]—or record the data from your storyboard:
- Story number (if any) or name
- Estimate—Estimated hours
Note: Total all tasks in each story if your tracker doesn’t, for this and the next two items. - To-do hours
- Actual hours
The spreadsheet will update these cells, using the formulas described:
- Total hours (To-Do + Actual)
- Gap (Estimate – Total)
- Percentage—Gap as a percentage of Total ((Gap/Total) x 100), rounded to whole numbers
- Totals for those three columns
Here are sample results from those formulas:
In the results, any completed stories will have the same number under “Actual” and “Total,” since there are no hours left “To-Do.” The “Total” column approximates the hours that will be required to finish incomplete stories by combining what was done with the owner’s guess at what remains. Over-estimates will appear as negative numbers because the “Estimate” will be larger than the “Total.” These are good. As mentioned before, if you over-estimate every task, you are almost guaranteed to complete all of your stories!
But you don’t want to over-estimate so much that you leave a lot of capacity unused, and thus don’t commit to as many stories as you safely could, skewing your velocity downward. For admittedly arbitrary reasons, I follow the Pareto “80/20” rule as a guideline. I thus recommend a goal of over-estimating by an average of 1%–20% per story every sprint. This has proven effective in getting teams to 100% while also filling up people’s capacities. However there is a danger in focusing on averages, because you can miss real problems in the details. This mistake is a cause of some business myths. People assume a good average result reported in a business article will apply to their organization, without looking deeper at the specific circumstances in which that result occurred, which may be very different from their own.
An analysis of the results in the spreadsheet above appears below. Presenting this kind of data to the team along with your analysis, even if just by e-mail, provides a factual basis for individuals to make improvements in the next Planning Ceremony. And the next Retro is not too late a time to discuss an earlier sprint’s results as a team. I get around the delay by running a preliminary analysis of the current sprint right before its Retro, then updating the team by e-mail with the final data. Even if some entries are not up to date in the Retro, we usually get close enough to the final results to be useful.
Example Analysis
In the last spreadsheet image above, we can see some indication of why three stories were not finished, those still showing ‘To-Do’ hours:
- S01 and S03 are going over their original estimates by more than 20%.
- The 0% figure on S06 seems good at first glance, but it isn’t really—seeing that most of its hours remain as “To-Do” tells you the team barely started on it.
Note: The assignees aren’t far enough in to know whether their estimates were off, so the ‘To-Do’ figure is just the original estimate minus the actuals. - The reason S06 was barely started might have been because a lot of the bigger stories were underestimated and took up more time than expected.
- The underestimate by 50% of S02 is not a big deal because the story was small; the underestimate of S03 was lower at 32%, but was a big hit in number of hours because the story was large (that’s what I mean about being wary of averages).
In general, the trend suggests the team needs to be more conservative on estimates. Start by asking for more details on tasks during grooming, making sure the list is really covering everything. Think through dependencies and risks more carefully, as these can take extra labor hours to address. And encourage the team to be more open with each other in questioning estimates.
Compare Capacities to Hours
Also compare actuals, estimates, and capacities, team-wide and by individuals. I illustrate several common scenarios in this section. The case in this table, where actuals outstripped the estimates, is the most common for new Scrum teams, especially if there were incomplete stories:
| Estimates | Actuals | Capacities |
| 244 | 285 | 305 |
Given that actuals still fell short of capacities, one or more of these explanations is likely true:
- Members are setting their capacities too high (not allowing enough time for their nonsprint duties). In the case above, this interpretation means they did not actually have 305 hours available. The number was closer to or below the actuals.
- Something or someone is preventing members from working on sprint tasks. Usually this is either a case of a Customer or manager going around the team to ask individuals for nonsprint work, or of unusual problems that crop up outside of the project and distract the team.
- Members are failing to front-load and thus running out of time to do sprint tasks. This is perhaps the most common reason when teams are getting started, though probably not the case in this example because actuals surpassed estimates.
Actuals rose above Capacities during the sprint in this table:
| Estimates | Actuals | Capacities |
| 244 | 285 | 276 |
Usually in this case one or more stories will be left incomplete. The team probably added a lot of tasks and/or to-do hours, meaning it should be more careful thinking through its tasks. I would also point out to the team it only allowed a buffer of 13% between its total estimates and capacity. This illustrates why I said earlier that I get nervous when people commit to more than 80% of their capacity.
In this sprint, assuming all stories were accepted, the team did a nice job of over-estimating by a little bit:
| Estimates | Actuals | Capacities |
| 244 | 230 | 281 |
But actuals fell more than 22% short of capacities. If this has happened a few sprints, the team can safely commit to more stories (and therefore more task hours) next time.
In the early going with a team, I talk about team-wide numbers with everyone, but discuss individual issues with each person privately. After the team has developed a level of trust, members usually don’t mind looking at personal numbers. I should note, however, that digital trackers probably make these numbers glaringly obvious to everyone, so the privacy point may be moot! When a member’s estimates went over capacity during the sprint, that means tasks were missed during grooming and planning and had to be added.
⇒ Steps: Improve Estimation
↑ The Sprint Process | ← View the Sprint in Retrospect | → Use Kanban for Flowing Work
[1] “Comma-separated values,” which any spreadsheet program can easily import and convert to its native format.