In Retrospect: About getting through your Sprint

This is the fourth of several posts in which I’d like to share some of the things we learned throughout more than a year 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 two teams of about 8 developers made in a period of 12 months, they apparently aren’t that obvious. So after having discussed our ideas about dealing with bugs, let’s talk about what you can do to get yourself through the sprint as efficient as possible.

About Stories

Be pragmatic

If, during the sprint, some story causes a lot of discussion and the product owner (PO) is not available to take a decision, cut off the discussion as quickly as possible. If it is a decision with a high reversibility – e.g. you can revert the decision without noticeable impact - just go on. But if the PO is really needed, put the story on hold. Obviously this is a waste of the team’s time, but the PO has to accept that his availability is quintessential.

Always discuss a story with the product owner

I’ve already said it before, and I’ll do it again; a user story is a placeholder for a discussion with the PO at the time you pick up the story. So before you start doing a more detailed breakdown with your pairing partner, consult the PO for the most recent information. It happened more than once that the PO attended a business review the other day that affected the details of a particular story.

Don’t talk about a story as ‘that 3-story point story’

At some point in time, we noticed that the team started to talk about a bigger story (that seemed to drag on and on) as ‘that 5-point story’. This continued for a few days until we discovered that nobody knew exactly anymore what the story was about, and more importantly, what its scope was. Worse, we already added functionality that wasn’t part of the scope at all. We then agreed to force ourselves to refer to a story by its title or purpose.

Try to start the sprint with the blocking story

Obviously you should start with the story that is going to be blocking for other stories, even if it is not the one with the highest business priority. Although this may seem obvious, it is quite common to lose track of any dependencies between many stories during the sprint planning. This is why we introduced a separate sanity check meeting to particularly look for technical risks or dependencies between stories.

About the Product Owner

The product owner must sit with the team at all times

You’ll be surprised to see how many product owners fail to understand how important their role is and refuse to sit with the team physically. In fact, some of them think that being a PO is a part-time job that can easily be combined with other responsibilities. We’ve learned firsthand that they are wrong.

Because our PO sat with us, he managed to detect conflicting business rules in discussions between developers more than once. And since written text can never prevent ambiguity, having him around all the time has saved us a tremendous amount of time already. At first, we thought that regular meetings should have been sufficient. But small questions about details or choices happen throughout the entire day. If that question is not answered right away, then the developer is either forced to make a (potentially wrong) assumption, or to put the story on hold. That may not seem a big problem, but just consider the theory that on average a person needs about 15 minutes to compensate for a context switch.

The product owner should proactively participate in the development process

Not only should the product owner sit with the team, he or she should proactively participate in the development process. If you don’t, you risk the chance that the team is building something different than what the PO intended. This happened to us when the PO provided a mockup to some team members. He then went off and didn’t look at the end-result until the end of the sprint. Only then he discovered that the developer misinterpreted the UI behavior of a particular part of the application. As a PO, don’t be afraid to sit with a team member that is working on some new functionality without being asked to. Also regularly join the stand-up meeting if you want to get a heads-up on what the team is doing that day.

About Making Progress

Don’t change the members of the team throughout the sprint

The velocity that was calculated during the sprint planning is based on the average focus factor of the team and the available working days. You may think that removing a team member simply reduces the number of working days, but it will affect the focus factor as well. So removing a team member will not necessarily have a negative impact.

Adding a new team member is a completely different thing. Firstly, you don’t have any historical figures to estimate the impact of the addition to the team. Secondly, that new developer wasn’t part of the sprint planning and missed some important discussions, even if he is very experienced. And third, he’ll need a whole lot of time from the rest of the team to get up to speed.

We knew of this when we were offered a new very senior team member, but we seriously underestimated the time it took to understand the functionality, to get used to the team’s development practices, and to really grasp the complexity of our architecture.

Focus on moving stuff to done-done
I keep reminding everybody that the entire team is responsible for getting stories to done-done. However, developers seem to have the natural tendency to ignore stories in any state following ‘review’. But never allow team member to pick up a new story until all the other ones are done. In worst case, let them do pair programming, pair reviewing or pair testing, or whatever is necessary to get to those stories to done.

Take special precautions when you are out-of-the-office the next day

If you know you’ll be out of the office the next day, consider the importance of the task you’re working on. If suspending it for a day isn’t a real issue (see next practice), just make sure you carefully write down where you left. If the work is important, finish the day by pair programming with a developer who can continue the next day.

Hand over work in the last week of the sprint

As a team, you don’t want to lose any time in the last week of the sprint. So if you’re out of the office the next day, and it’s the last week of the sprint, be very thorough in transferring the work to another team member. If you fail to do so, don’t look surprised when you’re being called by a team member for some answers. They have all the rights to do so if you jeopardize progress in such a way.

Don’t ignore the burn-down chart

I remember a particular day when the burn-down chart made a sudden dive down and we all assumed that the team just happened to be very productive that day before. Unfortunately somebody accidentally closed two very important tasks, but we didn’t discover that until the third week of the sprint. Imagine us struggling to explain that to our product owner. So, always investigate unexpected variations in your burn-down chart.

Track your progress carefully

One of the most recurring problems in our project was our failure to keep track of all the little details involved in completing a story. Stories are broken down in tasks, whereas tasks are broken down in lots of small OneNote items with a checkmark. The biggest problem was that not all developers were doing this at the same level of detail. Usually there was a correlation between that level of detail and the size of individual code check-ins. That’s why I’d advise you to rigorously use OneNote to keep track of anything that still needs to be done to complete the task. When you working on some code changes, and you discover or remember something else not directly related to those lines, add a check marked line in OneNote and continue as usual. A nice side-effect of this approach is that your check-ins tend to be much smaller and less susceptible to merge conflicts.

Switch pairs after two days of working on the same story.

We’ve noticed that working too long on the same story causes some developer to miss important details or lose track of the global picture. And not only that, we’ve seen that developers that were pairing for more than a few days started to include tasks that were never part of the original scope. That’s why we try to switch one of the developers every one or two days.

About Stand-up Meetings

Organize the stand-up at a fixed time of day

We’ve always scheduled the stand-up meeting at 9:30 in the morning, primarily because a few team members were accustomed to come in between 9:15-10:00. However, over time, some of those same members started to come in later and later, and we simply waited until all were in.

Keep them short

Our stand-up meetings tended to last too long too often. This was mostly caused by discussions that should have been taken off-line. We’ve improved on that, but as the architect of the team, I often use the stand-up to get everybody up-to-date on important decision decisions. In particular because some members start at 7:00 in the morning, while others don’t come in before 9:30.

Focus on the stories and not on the team members

We’ve learned that traditional stand-up meetings where the ‘microphone’ moves from one team member to another don’t give enough insight in the risks and progress of the stories on the board. That’s why we tried using the board as the centerpiece by discussing stories one by one, starting with the one that is closest to done. This has significantly improved understanding the status of each story, and gives team members more room to work on stories together.

Pay attention to the remaining hours

We had no trouble discussing the status and the challenges of a particular story during the stand-up meeting. But somehow we often forgot to query for the remaining hours of the tasks associated with that story. Being aware of those hours makes it more natural to mentally compare the work that still needs to be done against the hours still left and whether or not that is feasible.

Stand-up, don’t lean

Many developers don’t seem to understand why standing is so important in a stand-up meeting. Why can’t you lean against a shelf, on a chair, or against the wall? Because that makes that position to convenient! The whole purpose of the stand-up meeting is to keep it as short as possible. So the simple requirement to stand up motivates them to spend as little time as possible on conveying their status.

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 sharing my opinions on some of the practices from Extreme Programming.