This can be a good thing for stories that have a low priority. But the higher priority stories must be refined. If this is not done endless discussions will take place. Or the Sprint Review will be a big disappointment. So regularly plan refinement sessions.

Without planning the outcome of the Sprint Goal will be like the lottery. Prepare the Sprint Planning very well. How much capacity does the team have this sprint? Is everybody available, is anybody on holiday? What is our normal velocity? How much Story Points do we assign to the selected User Stories? What exactly is the Sprint Goal? If your team never gets all the selected User Stories done, it might be a good idea to spend more time on the Sprint Planning. Sounds obvious. But this is a very common mistake.

After the User Stories are selected from the backlog, they have to be split up into tasks that take no longer than 8 hours to complete. If you don’t do this the so called tasks will be dragged to In Progress on the Scrum Board, and remain there for a long time. During this period no burn-down is visible, so progress can not be tracked. And it’s very hard to divide the work in the team because the underlying tasks are not visible.

Maybe one of the hardest things to change in an organization. People need to be transparent on what they are doing. This may be a bit frightening in the beginning. Because people don’t like to explain they failed to complete a task they promised would be ready. It feels much safer to hide behind vague stories, complex language or other non relevant things. They might think it’s better to promise nothing and keep the tasks as vague as possible. This gives them a certain amount of freedom to do whatever they want. But this behaviour will not help the team at all. The Scrum Master must coach the team in this. Everybody must feel safe enough to be transparent and open about mistakes. This is the only way the team can learn and improve. The Scrum Master must also learn the team to help each other in this. In the end nobody should be hiding anymore.

At some point organizations try to improve their Scrum process by implementing tools. Nothing wrong with that because this will really help with the administration of the backlog. And it can provide useful information, like team velocity and burn down of the sprint. But it does not always help the team. Teams need a clear overview of everything that is going on. A scrum board hanging on the wall is doing that very well. A tool can be projected on a large screen, but most of the time it is not as clear as the physical board. Sometimes you have to find a compromise in this. For example: Do the backlog and user stories in a tool, but do the sprint progress on a board.

The Scrum Master has to remove all impediments. That is handy! Give him all the things that we don’t like to do. Let him fill in the bureaucratic forms, let him apply for authorizations, let him book all the meeting rooms, hell, he can get coffee for the team at least three times a day. This is a bit exaggerated, but be aware. Impediments are only impediments if the work of the team is blocked, and it is hard or even impossible for them to solve this. The Scrum Master must be very critical in this. The team should learn how to solve most of the problems themselves.

You can do stand ups, sprints of two weeks including a sprint planning, but that does not automatically make it Scrum. Do you really deliver a shippable product every sprint? Or do you actually deliver something shippable every two to three months? Have you really sliced up the work, or do the tasks simply continue over sprints? It is not easy to deliver something useful every sprint. Certainly not in the beginning of your product development. What could you possibly have after 2-3 weeks that users can work with? Is it even safe to deliver after such a short period? Is it compliant, secure and stable enough? This is all very true. But it is still very important to get your stakeholder feedback after every sprint. Just deliver something that works. Were people can comment on. You will not bring an immature product to production. But you do need the feedback. Is it Scrum? Well maybe not always. But as long as your feedback cycles work well you should be ok.

Every sprint the Product Owner has to set the priorities. This does not mean he can do whatever he wants. The Scrum team must understand the goals of the Product Owner, so they can define the right Sprint Goal. If the Product Owner constantly changes his priorities the team will get confused or even frustrated. The Product Owner often has to deal with a lot of stake holders. He cannot satisfy everybody at the same time so choices need to be made. It is important the Product Owner is very clear on his vision, and stick to it. Agility means adapting to changing circumstances, not pleasing everybody. Not even when there is pressure from senior management. Easy to say, I know. But very difficult to do.

Maintaining a backlog is a lot of work. It is quite common that backlogs are composed at the start of a Scrum Team. Many items are added that need to be implemented at some point in the future. Over time the Product Owner tends to add new backlog items before the sprints, ignoring the older items. At some point the backlog consists of a long list of items that are no longer relevant, or might be relevant but nobody knows anymore. Every backlog needs some structure to align with the vision of the Product Owner. For this high level User Stories like Epics or Features are introduced to add hierarchy to the backlog. This can be helpful techniques to keep the backlog clean. The most important technique however is discipline.

The goal of the Retrospective is an inspection of your own Scrum Team. But that is not so easy because you have to be critical on yourself and your fellow team members. It is much easier to complain about others who are not present in the Retrospective. The Scrum Master has to coach the team in this process. Everybody should feel safe to say whatever is needed to improve the team. If the team finds this hard you could start with the process and the tools. But relationships and people must be addressed as well at some point. The Scrum Master must make sure the team is mature enough to handle this.

Scrum is practised in many different ways. Not everybody uses the framework as it is meant to be. So people who come from other teams or organizations may have different experiences. This can easily conflict with other practices. If possible the best approach is to stick to the framework. Again the Scrum Master has to coach in this. (You can see how important the role of the Scrum Master is). If deviations are made in the team the Scrum Master must be aware of this. He should make this very clear to the whole team.

In large organizations, and maybe also in small ones, teams are never fully independent. Other teams may need services from the team, or they might depend on a piece of software the team has to implement. Collaboration is very important. The Product Owner has to make sure this collaboration is facilitated. If not the team will become a bottleneck in the organization. A common pitfall you see in organizations that just start with Scrum is that every team is only occupied with themselves. Everything is so new they feel they really don’t have time for the needs of others. This behaviour will lead to a decrease in productivity of the organization as a whole. It might even make senior management say that Scrum is a failure. Train your Product Owners very well so this is avoided.

Not a problem that is specific for Scrum, you see this everywhere. People who deny services because you did not exactly follow the rules. Examples are: you emailed the request, but it should have been faxed. You used the wrong version of the request form. Your manager must approve this request before we can put it on our backlog. The Agile Manifesto says: Individuals and interactions over processes and tools. Everybody has the responsibility to help others achieve their goals. Of course, rules are there for a reason. But try to find out why it went wrong. Improve your procedures if that helps others. And most of all, find out what it is the other needs from you. Instead of denying a request, ask what his intentions are, and help him to achieve his goal. This kind of behaviour is very important to make your Agile organization successful.

Another misunderstanding. Documentation is no longer needed in Scrum. The Agile manifesto says: Working software over comprehensive documentation. That is, while there is value in the items on the right, we value the items on the left more. So you do have to document stuff, but only document what really adds value. Make sure this documentation complies to your quality standards.

Do you recognize this: People show up late at stand ups, or don’t show up at all. People work on other tasks that are not even defined in the sprint planning. People don’t update the scrum board. People don’t finish tasks, they just leave them in progress. People try to avoid meetings like the Retrospective and the Sprint Planning. All signals of low discipline. Needless to say this has a strong negative effect on the team and it’s performance. Discipline is key in self steering teams. The Scrum Master has to coach the team members. But if people are not willing to cooperate, his or her manager should take action. Eventually the manager should remove these people from the Scrum Team, because their behaviour will constantly threaten the Sprint Goal. Sounds harsh I know. But if you want Scrum to work everybody in team must contribute.

After two or three weeks of hard work the team is eager to show their achievements. Very often they have managed to make something complex work. For example: They managed to connect two systems, they managed to install a piece of software, or they finally found the solution to a very annoying bug. The engineer likes to share his new insights and successes with the rest of the world, and starts to explain about it during the Sprint Review/Demo. Unfortunately most of the time the Stakeholders and the Product Owner don’t care how the engineer did it. They want to know what added business value is now available for shipping in the product. Their want to give feedback on functionality and usability. The engineer has to remember this. Tech stuff is for the Development Team. In the Sprint Review the Product Owner must be able to explain the progress on a functional level. It is a nice gesture to let the developers demo their deliverables, but they must keep it functional.

You worked very hard to deliver the Sprint Goal and you are ready to demo the results during the Sprint Review. What a disappointment it is if your stakeholders do not show up during this event. Apparently they have other more urgent obligations. The signal this gives to the team is very negative. Why should they bother to work so hard if the people they do it all for don’t care? The Product Owner has the responsibility to make sure the stakeholders are present during the demo. Being a stakeholder comes with obligations. They should be aware of this. If they can’t be present maybe somebody else should take this stakeholder role.

One of the reasons development and maintenance were split up is probably because incidents constantly interrupt the work. Scrum says nothing about maintenance, but DevOps does. I will discuss more about this in the DevOps section of this website. To give a few tips: if this is bothering you try to administer how much time in general you spend on incidents. Take this into account when the next sprint starts. Maybe it is even possible to extend the team. If other things keep coming in besides incidents you really need to have a good conversation with your Product Owner. He should be aware that this is constantly threatening the Sprint Goal. You can always try to reserve some space for unexpected urgent matters, but if this is a constant thing you will not be successful.

It’s not easy to create a Scrum team that is totally independent. Organizations are often structured around services. To give a few examples: The team needs access to a test environment, but the test team is not available. The team wants to load some test data, but the DBA is not available. The team wants to connect to another system but the firewall is closed, and the firewall team does not have time to fix this. Scrum teams can never do everything by themselves. The organization needs to make sure the services the Scrum team needs are available at any given moment. The best way to achieve this is to automate everything. I will discuss this in more detail in the Continuous Delivery section of this website.

The Scrum Master is the coach of the team, but he or she also needs to remove all impediments. This requires different skills from the Scrum Master. Coaching is listening to people, observing and giving feedback. Removing impediments requires executive power. Talk to the right people, put pressure where needed. Use your network, convince people, compromise and get things done. This is where the former Project Manager will excel, because this is what he used to do. But the typical coach will not be very good at this, which will lead to unsolved impediments. Personally I think the Scrum Master is not the best choice for removing impediments. I think this is where management comes in the picture. They usually have the strength to break through barriers, and get things done for the team.

Basically this is the same problem as not defining any tasks. If the work is not very fine grained, a task will remain in progress for a very long time. The only way to solve this is to spend time on planning en refining. Tasks should take no more than eight hours to complete. If a task stays in progress you are either waiting for somebody else, or you have not defined your task very well.