Often when thinking about the productivity of a Scrum development team, you may think about velocity, the metric used to measure how much the team gets done in an iteration. However, the velocity is used to determine how much point a team can achieve on average on a normal sprint and then determines how many points they will agree to achieve in the next sprint iteration. The velocity should not be used to determine if the team is productive or not, it’s just a simple indicator based on past sprints.
Having a high velocity does not mean that much. What matters is the result at the end and what the team has produced. Pushing a team to drastically increase their velocity has no sense. It could be more costly at the end because it can lead the team to cut corners on acceptance testing, skip fixing bugs or minimize refactoring just to reach the velocity.
If you want to increase the velocity of your team, you should focus on the optimal velocity over time rather than maximized velocity, which considers the quality of the end product. To help your team to be more productive, let’s review several tips and tricks that I apply.
1. Remove impediments
One of the key role of the Scrum Master is to ensure that impediments are taken into consideration early in the development process. Asking good questions during the writing of User Stories, ensuring developers have all they need to do the work, being a shield for the development team so as to not be disputed by stakeholders are tasks that the Scrum Master has to do every day.
To do: In case the team is disrupted, ask them to redirect questions and support requests to the Scrum Master.
Pro tips: From my experience, distractions are the primary reason for reduced productivity in a team. The team loses focus because of these distractions and cannot really justify why they delivered lower than normal productivity.
2. Team size
To be efficient, the team should be small, something in between 3 to 9 persons. Above this limit, communication problems can occur and you lose more time in discussions. If your team is bigger, you have to split it into one or more teams.
To do: Ensure the size of the team is good (not too big) and fits the project needs. Also, take care of the turnover, as introducing new members every month on the project won’t help you deliver any faster.
Pro tips: Working with a big team with Scrum is not a good idea. The more you do, the more people will lose information and the more effort required to make everyone aware of everything that is going on.
3. Daily meetings
It can be repetitive to say but it’s really important that all the team members attend the daily meeting every day. It should not take more than 15 minutes per day and will give an overview of how the work is progressing. If a conversation gets off topic, it should be postponed after the meeting. A parking lot can be created to store all the points that have been raised during the daily meeting and which need to be answered that day.
To do: Be efficient, get prepared before the meeting, have in mind what you have done the past day, what you have to do today and the impediments you encounter.
Pro tips: Communication is key in Scrum; this moment is very important to exchange.
4. Product backlog
Everything starts from the backlog, and maintaining it clean and clear is mandatory. By reading the backlog, you should understand where the application goes and have the vision of what needs to be built in the near future.
To do: The more accurate the User Stories are, the less time the development team will waste trying to understand them. Ensure that the User Stories have enough details. Reorder them if needed, change their priority and move them to the icebox while waiting for the next release.
Pro tips: A common issue I have encountered during an Agile project is the fact that PO don’t spend enough time on the backlog for a lot of reasons. Ensuring the backlog has enough ready to use User Stories for one (at least) or two sprints is very important.
5. Continuous improvement mindset
Scrum is a continuous improvement process so it’s normal to improve the whole process and not just the software. Also, known as « Kaizen », the idea is to find something to improve at the end of each sprint and accomplish it during the following one. In doing so, you will be able to remove one problem at a time and help progressing.
To do: During the sprint retrospective, find one concrete action to achieve that will help the team. To make it work, someone has to be responsible for executing the action.
Pro tips: Start with small actions, something easy to do in a sprint that won’t take too much time. Ask each attendee for suggestions during the sprint retrospective, choose one and discuss the plan to achieve it.
6. Interruption buffer
When running an application in production, you have to deal with maintenance and delivering new features, and sometime interruptions occur. It can be an urgent bug that’s been reported or another team that requires a developer to help them. It’s impossible to ignore the rest of the world when delivering a product. You have to deal with these interruptions in the current sprint.
What matters is your ability to face this kind of situation. A buffer scheduled in all your sprints could help you to avoid scope changes.
To do: Create a US with a small amount of points and add it to the next sprint. The number of points depends on the number and time consumed by your current interruptions.
Pro tips: I personally book something like half a day of a developer per two weeks to handle this kind of situation. In case no interruption occurs, this time can be used at the end of the sprint to help on other tickets or even better, let a developer do some R&D for the project.
7. Make work visible
It’s a known fact that making your work visible helps the team to be more responsible for the delivery. Having metrics and other charts printed and displayed on walls also helps stakeholders and colleagues to know how the product is moving forward.
To do: Update the burndown chart on a daily basis, display the Kaizen you want to achieve, show the customer or team satisfaction. You can also display the roadmap of what you are building to share the vision. There is plenty of information you can display that will help everybody get the idea on how things are going in a second.
Pro tips: I like to make all information visible for everyone on a wall. Displaying data helps the team to deliver quality and involves all the company.
8. Avoid multitasking
Multi-tasking happens all the time, companies praise it. But multitasking reduces productivity and the quality of the end result. When a developer starts working on a task and has to stop for something else to finally go back to the original task, he lost all the time he spent understanding the software. Asking someone to give up what he is currently doing has an invisible cost that you should be aware of.
To do: Limit the work in progress for all team members. Be vigilant that the developer doesn’t get overloaded working on several US at the same time.
Pro-tips: It’s a good habit to limit our work in progress and focus on finishing work, not starting work.
This list can be bigger, but if you manage to apply them to your project, you will see benefits at a low cost. There’s nothing complicated, just common sense here.
If you apply something else in your team that works or doesn’t work, feel free to share in the comments section.