This is an excerpt from the book Scrum Your Jira: Your Waterfall Organization Transformed into Multidisciplinary Teams.
What Is the Goal of a Scrum Sprint?
A sprint consists of a number of stories that the team needs to complete, and each story has a number of points assigned to it. But what is the goal of a sprint? Some stories might not be finished at the end, so is it to produce as many story points as possible? Let’s examine this more closely. Let’s assume that indeed the goal of a Scrum sprint would be to produce as many story points as possible. Force the team to work overtime! OK, that does not work because it is not sustainable. On average, you will end up with decreased productivity as the bugs will pile up and your team will be demotivated or even get sick.
What else can we adjust? We could be optimistic: let’s just add as many stories as possible into the sprints. If the team was able to do X story points before, it might be able to do that again!
What is the result of this? Even though you might end up (at least, in the beginning) with more finished story points on average in your sprints, consider the following disadvantages.
You will end up more often than not with unfinished sprints. There will be constant pressure on the team to be faster (as opposed to producing more value for the customer—which is not necessarily the same). There is no longer a goal. If the sprint cannot be completed because of too many tasks, the sprint as a concept loses its meaning and becomes more like a backlog.
Because in Scrum the team decides which tasks to work on and in what order, “uncomfortable” (but maybe valuable) tasks might remain unfinished (there is always something “more important” coming up) and dragged along to future sprints. The product owner then has to require people to conduct work in a specific order, and the concept of a sprint again loses its meaning, and the team loses its responsibility for the sprint.
The point is that you can fool yourself into thinking that an increase of story points per sprint (if that happens at all, considering the first two points in the list above) actually leads to a higher business value. The concept of “more story points = better” is actually the cause of delay.
If you are dragging half-finished stories along, their business value will remain at zero, no matter how much work has been put into them.
Stories that are worked on over the course of many sprints become more expensive, as their business value remains unrealized and people have to remember again and again what they were about. They also slow down planning and impede the focus of the team when selecting the next story to work on. “Management thinking,” that 100 percent workload of the team will maximize the business value of the project, is faulty.
From a management point of view, this idea has a scary outlook: your team completed its work and now…what? Do you send them home? Do you have them start another sprint? Do you add new stories to the completed sprint?
It’s important to get away from the idea of 100 percent workload being optimal. That is local optimization to a more global problem. When the team is done with the sprint, the team is done! Let the team decide what to do with the remaining time. People are self-motivated, they generally like to learn. Give them the opportunity to read books, attend conferences or seminars, research new technologies, or just take a break. Use the time for team-building, improving the office atmosphere, or generally cleaning up things that have piled up (there is always something). Encourage them to discuss what projects or program parts could be scrapped. But let it be the team’s time. Set the completion of sprints as the goal and have the team celebrate their success!
If you are afraid that, with such a positive outlook, they will aim for less and less each sprint, re-examine your own views and ask the five “why” questions, beginning with: Why are they not motivated to want to work on the project? Asking that question of yourself is much more productive than trying to coerce your team into working more…which usually just means having them spend more time in the office staring at the screen without really being more productive. Yes, the team has to lead the project; it is theirs. If you are uncomfortable with that idea, maybe Agile methods are not for you. But if you want to tap into the power of Agile, team ownership of the product is essential.
As a side note, if you really want to maximize the story points, maybe eXtreme Programming (XP) is for you (this is another Agile method). Here, there are no “sprints” but the team works together on one task at a time—with the product owner determining the sequence of the tasks. The advantage is that individual tasks are finished as quickly as possible, with the whole team behind them. You get quick returns, although at the cost of not being able to utilize parallel work, plus the possible overhead—just imagine seven people standing around a single computer telling the eighth what to do. On the upside, you will have a strong emphasis on knowledge sharing and will possibly improve team communication.
EXTREME PROGRAMMING · eXtreme Programming is a project management method on the team level. It consists of a set of techniques to improve software development speed by having the team work on only one task at a time, having developers work in pairs, and releasing individual features instead of waiting for the full product. It requires an advanced continuous integration system.
XP is a powerful method to consider. Even if you prefer Scrum, I would suggest testing XP as a team exercise. Have your team work on one task together until it is finished, and only then move to the next. It might actually be fun for the team to sit around a single computer and combine their knowledge, solving each problem together.
