Sprints matter, but why?
Some Agile Software Development methodologies/frameworks, like Scrum, have the concept of Sprints, but why? Sounds like an easy question to answer if you are working with software development, but I believe that many people have not thought about it, think of it slightly wrong or don’t get the most important aspect of sprints. If you are a practitioner of Scrum, then sprints are part of your life already, you are using them, but perhaps you never took time and questioned why sprints exist? When I’ve asked this question to a few people, I’ve gotten answers like this:
“We have sprints, so that we (the developers) can work in peace for some time and not be disturbed by ever-changing requirements.”
That is somewhat true, and one benefit of sprints but then again, you could also have said, let’s only make changes to our plans on Fridays when there is a full moon. That would give your developers peace as well, right?
“We have sprints, so that we can learn from the past so that we become better.”
Also true in a way, you can use the end of the sprint as a reminder to reflect on what went well and what didn’t, but same as above, you could also just set the alarm and say: The first Friday ever month, we’ll stop and reflect to see if we can learn something from the past in order to be better in the future. That would also give you a time for reflection, right?
“We have sprints, so that we can predict when we are done with the whole project or a milestone within.”
Another true statement in a way, if you start to understand how much work you can accomplish within a sprint, then you can estimate when all (known) work will be done, using “sprints” as a time unit, but then again, why not just use another measurement like: “User Stories Completed per Week/Month” for your velocity calculation? That would achieve the same thing, right?
“We have sprints, so that we can practice delivering production ready code at specific milestones as every sprint end is like a small milestone.”
Now we are getting close, but we still miss the point. It’s true that you do develop a mindset of delivering “increments” of your project every sprint, but once again, you could also say that we have deadlines to meet at several specified dates and that would achieve the same thing, right?
Sometimes people are unable to answer the question and have state comments like this:
“Sprint planning in Scrum is taken a bit too serious.”
“Sprints are good, but we don’t think it’s such a bad thing if we slip our sprint goals in the middle of a project, as long as all is completed at the end of the project”
“We have a more pragmatic approach to Scrum.”
You can see the somewhat skeptical answers both to my question and in some ways towards Scrum, and this is where I think people miss one important thing.
Scrum (and other Agile methodologies) has built in features to promote teamwork.
Scrum (and other Agile methodologies) has built in features to promote teamwork. One of the more important ways of promoting teamwork in Scrum is the use of Sprints. If we don’t take sprints seriously in Scrum, we would need to add other mechanisms to achieve the same thing. Let me give some examples.
If we don’t take sprints seriously in Scrum, we would need to add other mechanisms to achieve the same thing.
When eXtreme Programming, XP, was popular, we often said that stories and tasks should be written on small enough pieces of paper so that enough could be documented, but not everything. Instead, you were incentivized to go and talk to “the customer” and other colleagues to get more information and once code were written it had to be done as a pair. Can you see how that drives teamwork and collaboration? Writing fully specified User Stories in a modern digital issue tracker would remove the need to go and talk to others, hence not encourage teamwork in the same way. There are more things in XP that drive teamwork, but I’ll not mention them all here.
In Kanban, you are supposed to set up “Work in Progress, WIP, Limitations” on your Kanban Board, so that not too many user stories or tasks can be in one stage at the same time. If the WIP limitation is hindering you from pulling a new task to work on, then you are instead asked to go and work with others so that this temporary “blocker” is resolved. Once again, a clear sign of how Kanban promotes teamwork.
In Scrum, there is no guidance of paper sizes, pair programming, Work in Progress Limitations, etc. (you can add it yourself If you want) but Scrum do state that “the sprint is the heartbeat of Scrum”. As a Dev-team you collectively commit to the work that will be delivered during the sprint. You succeed or you fail the sprint goals as a team. From the beginning till the end of the sprint you collectively do what you can to succeed with the sprint and don’t look any further until the sprint goals are met. There should be no one that thinks: “I’m done with my tasks this sprint, so I have nothing more to do” or “my workstream is done, hence I’ll start what should be done in the next sprint”, in Scrum you think as a team, and you succeed with your sprints as a team.
sprints and the agreed upon sprint goals are the number one mechanism in Scrum that promotes Teamwork
So, my conclusion is that sprints and the agreed upon sprint goals are the number one mechanism in Scrum that promotes Teamwork, it’s the number one reason sprints exist in Scrum. Remove it or take it a bit less seriously and you lose almost all mechanisms that drive people to work together.
Remove it or take it a bit less seriously and you lose almost all mechanisms that drive people to work together.
“Why don’t all of us just work from the backlog as much as we can during this sprint, and we’ll see how much we get done?”
Because it’ll not promote teamwork in the same way, since you don’t have that clear goal of what you’ll achieve together. Everyone is more or less just “running as far as they can” without looking for people that fall behind. It’s better to first agree upon one (sprint) goal and then ask for additional work if you, as a team, feel you are done early.
“Why do we care if we slip a few user stories to the next sprint?”
Slipping one or a few user stories may be ok, but it’s most likely not a good thing if the team at the same time didn’t do everything they could to pass the sprint goals together. For example, if someone felt they were done and started something new rather than helping the team to complete the sprint goals in time. This is something I’ve often observed in teams that decide to work with “workstreams” or have specialists that “only do one time of work”. (Note: it’s completely ok to have specialists in a team but the collective ownership is the difference and the incentive to help each other even if you are not the expert.)
If you take teamwork seriously, you should take sprints seriously as well, at least if you have no other mechanisms that encourage your team to work together.
So now you know. If you take teamwork seriously, you should take sprints seriously as well, at least if you have no other mechanisms that encourage your team to work together.
Initially posted October 2022, on LinkedIn, by Kristofer Liljeblad