This is the second of several posts in which I’d like to share some of the things we learned throughout more than 14 sprints of Agile development using Scrum. Some of them might appear as open doors, but I wish I knew or thought about those before I started that project. Just by looking back at the mistakes a team of 10 made in a period of 12 months, they apparently aren’t that obvious. So after having discussed requirements management, let’s talk about the sprint planning.
Don’t ignore holidays and days off throughout a sprint
When calculating the velocity for a sprint, it’s quite common to determine the number of working days and multiply these with the estimated focus factor for that sprint. So if somebody’s holiday ends somewhere throughout the sprint, it seems you’ve everything covered. But don’t forget that people need time to get up to speed on what’s going on in that sprint. Many aspects are not written down, especially doing sprint planning meetings. Somebody else has to spend time to update that person. So either remove an extra day from the available working days or adjust the focus factor.
Account for the (structured) absence of senior team members
This one is really about two scenarios. First off, any software development book will tell you that part-time team members will be less productive than equally experienced full-time team members. The fact that somebody is always out of the office on Tuesday requires him or her some time to get up to date on Wednesday. He may even have been working on something on Monday and didn’t find the time to transfer the task to somebody else. That on itself may cause some slight delay, especially if somebody else depends on it.
The other scenario happens when the most senior developers are out of the office for a few days. Normally, those developers will be the ones most capable of catching subtle but important design violations or critical bugs during peer reviews. However, when they’re not in, somebody else will take over the review tasks (hence: peer reviews), and they might not detect these subtle problems. If it’s a bug and you’re lucky, chances are that the skilled tester in your team might find it. But design issues (a.k.a. technical debt) may not become a problem until later in the sprint. Worse, it may even appear that the focus factor was higher than usual. But the fact of the matter is that those decisions will haunt you later on in the project. Deal with that by either reserving some time for ad-hoc reviewing or refactoring.
Have shorter planning earlier at the day
Every sprint planning meeting we had to plan after lunch somehow was a lesser success than the ones before lunch. Obviously, the lunch itself is a primary reason for that. But most people in my office start early, so by the time lunch has finished, they’ve been working for 4-5 hours already. By then, don’t expect them to be focused for another 2-3 hour.
Everyone is responsible for keeping it short
Yes, it’s the Scrum Master who should help the team to focus the sprint planning meeting on its purpose. But that doesn’t relieve anyone from keeping the meeting short. Don’t start a lengthy discussion on how to functionally solve a problem if that’s not absolutely necessary. If the product owner hasn’t done his homework properly, force him to move that story to the next sprint. Also beware for technical people who like to let everybody know how much they know. Just propose to continue the discussion outside the meeting (he still may have something useful to share), or cut him off if he’s not willing to comply. Also, don't discuss details that won’t affect the estimation. Remember, a user story is a placeholder for having a more detailed conversation with the product owner at the last possible moment.
Help the product owner to focus the meeting
Here are a few things you can do to help prevent the product owner from wasting the time of the team in sprint planning meetings.
1. Don’t allow him to propose technical solutions
2. Don’t allow him to influence the estimations
3. Force him to use a checklist while preparing the user stories so that they include important aspects as the How-to-Demo, the impact on other stories, and to make sure they comply to INVEST as much as possible.
4. Let him read this excellent summary of product owner responsibilities
Schedule breaks every 45 minutes
Regardless of the actual length of the meeting, schedule a short break regularly. People are simply not capable of keeping focused for a prolonged time. Even if it seems the discussion is almost over and you ‘only need to discuss two more stories’, it never is. As an extra tip, make sure there is sufficient water and/or soda on the table. I’ve found that can help extend the time people can focus.
Don’t discuss the technical solution during the meeting
We experimented a lot with the length of the meeting, whether or not to discuss the technical details and when to start doing story point estimations. We even tried splitting it up into two parts such as explained in the excellent Scrum/XP from the Trenches. But what worked best for us is to schedule a single meeting in the morning lasting about 2-3 hours where the entire team participates. We go through the stories selected by the product owner and try to identify the important aspects that might impact the effort required. We then estimate the size of the story in story points, and continue with the next story until the sprint is full enough.
Right after the meeting – but typically after lunch – 2 or 3 seniors will sit together and scan the sprint backlog to find the most risky or technically complex stories and discuss them in more detail. They may even start writing down some notes about the proposed solution or note some functional questions that weren’t covered in the sprint planning. Then they’ll use that new information to reassess the original estimate. Even though we do like to involve the entire team, we noticed that only the more experienced developers will participate in the technical discussions anyhow.
Re-estimate the remaining stories from last sprint
Ideally your team will be doing everything they can to get the stories to the done-done state. Unfortunately, in reality we are often faced with unexpected problems that prevent you from doing that. Obviously, those stories don’t count for the final velocity calculation, but you still need to finish them. In earlier sprints we roughly reserved the first one or two days of the next sprint to finish those stories. But quite often we didn’t know exactly what still needed to be done. What has worked a lot better for us is to simply reschedule and re-estimate those incomplete stories similarly to any other product backlog item.
Consider combining user stories that deal with similar business rules
I remember a situation that we had to realize four related different business rules. Because of their relative complexity, we decided to treat them as separate stories (using the Business Rule storyotype obviously). We did consider any potential conflicts, but that all seemed fine at the time of the meeting. You can guess what happened. Somewhere after implementing the fourth business rule we discovered some serious functional conflicts that we couldn’t solve without extensive discussions with the business and some significant rework. For this particular situation, we concluded that if we had combined them in one single story, we would have detected this much earlier.
Only accept stories that are well defined
As I mentioned before, a badly prepared user story can seriously hamper the sprint planning meeting as well as the sprint itself. We’ve been forced to accept such a story in the beginning of the project a few times, but some of those have seriously screwed up some of our sprints. Especially be suspicious when a product owner claims he still needs to discuss ‘some minor items’ with the end-user. It’s not uncommon to have some story lingering throughout the entire sprint and never reaching the done-done state. Also beware of stories which name resembles ‘various changes’. That’s why we decided not to accept any of those stories anymore. Again, to help the product owner, participate in regular backlog meetings or propose a user story checklist.
Include only a few bigger stories
Having too much bigger stories in a sprint increases the risk that your team won’t be able to finish that last story at the end of the sprint. A bigger story usually involves more review work, more rework, more testing effort and suffers from a higher change in estimation deficiencies. If you can’t get it to done, you won’t be allowed to include its story point estimation in the sprint’s velocity. Therefore, make sure you have a few small low-risk user stories that you can use to finish your sprint in a clean way.
Don’t include too many critical stories
At some point of time, one of our sprints included quite a lot of technically complex stories that could only be done by the most senior developers. According to our product owner, those stories were essential for some business demo. Because of the same things I mentioned in the previous practice, we ended up not finishing an important one that also happened to be important for some of the other, less critical, stories. During the retrospective we decided that the next time, we would make sure we kept the number of critical stories low and move them to the beginning of the sprint. Additionally, we decided to require pair programming for all critical stories.
Plan a story for every deployment
Throughout the project we occasionally had to deploy a status-quo of the system to an online demonstration server. As we were using automatic deployments anyhow, that usually wasn’t supposed to cost a lot of time. We didn’t get the time to build a sufficient level of code coverage for the presentation logic, so we always explicitly noted that bugs may still occur. But somehow the product owner almost always managed to demand some last-minute changes such as modified test data, disabling some features that were not working yet, and other minor changes that he deemed necessary for a successful demo. Even if you employ automated testing of the entire code base, I would still schedule some time for that demo. If you don’t need it, you’re lucky and you might finish an additional story. If not, you at least covered your tracks.
Don’t let anyone influence estimations
Yes, guilty as charged. In fact, I remember a particular story that involved some non-trivial changes to the architecture. As the architect, I already spent some time doing a bit of preliminary design upfront and had a fairly good idea how to solve that particular problem. So during the sprint planning, I explained the rough outlines of that solution and asked for a group estimation. They responded with a much larger figure than I had expected and which started me to explain why I thought it was “quite easy to do”. Obviously I badly influenced the re-estimation with that. You can guess how well that went for us…. Anyway, Beware of words like "just", "only", "nothing more than", etc. And don’t allow people to overreact on other people's estimations ("What?? That much!"), as this will influence the estimations surely.
Postpone the task breakdown until the moment the story is picked up
In the beginning of the project we still broke down a story into tasks as part of the sprint planning meeting. Then, right after that meeting, we refined all those tasks and assigned estimations in hours matching the amount of story points assigned to that story. However, we quickly discovered that those tasks were typically not well defined, or did not match the real work well enough. That made us change our tactics (and we still do it like this) by postponing the breakdown until somebody actually started working on it. At that point of time, a minimal of two developers would discuss the details and manage to get a much better breakdown. To keep the benefit of a burn down chart, we do assign a placeholder task to every story with the total amount of hours available for that story.
Don’t assign all working hours to the story
Suppose you have estimated or determined your teams focus factor to be 50%, then each story point will take 16 man-hours to complete. You might be tempted to apply the same calculation to the tasks for a particular story. However, we’ve found it to be wiser to assign only 75% of those hours to the tasks and keep 25% as slack for any continuous or intermittent activities. In our team, it also appeared to have a nice side-effect. Developers tend to try to stay within the assigned hours of a task. So even if you have a setback, it won’t immediately blow up your sprint. As an example, consider a story that is estimated at 5 story points and a focus factor of 50%. We will divide 5 SP * 8 hours-per-day / 50% * 75% = 60 man-hours over the tasks of that story.
Reserve a task for the peer review
Peer Reviews should be part of the ordinary work required to finish a story, and thus also be part of the definition-of-done. Earlier in our project we didn’t explicitly reserve any time for it and assumed the developers would account for that themselves. But after we were constantly faced with a lot of rework after all tasks were supposed to be done, we started reserving about 25% of the story’s hours to a dedicated task named Review & Rework. The complexity of the story ultimately influences whether or not we assign the entire 25% or reduce that value a bit.
Complete the sprint planning meeting with a sanity check
At the end of the sprint planning, ask the team to reevaluate the sprint backlog for a minute. Let each of them decide for themselves whether the entire list of stories selected for that sprint still seam feasible. We usually use this moment of reflection to see if there are any undesired dependencies, or if we need to reorder stories to move some complexities to the beginning of the sprint.
And with completing the sprint planning I’ve completed part two of this series. Remember that these are the experiences of me and my team, so they might not work as well for you as they did for us. Nevertheless, I’m really interested in learning about your own experiences, so let me know by commenting on this post or tweeting me at ddoomen. Next time, I’ll be talking about how we deal with bugs.