Ask yourself why sprinting is hard

Sprint is a time-box; it’s not a scrum artifact or ceremony. It is not a role like a stakeholder or product owner. Still, there are a number of ways this time-box holds the scrum team back and make things difficult.

Developers, scrum master, product owner, management and stakeholders; all play role to make this time-boxing harder than usual. A scrum team needs to get out of the bad habits, anti-patterns to achieve the full potential of agile development. Let’s see what can make a sprint hard and I believe, every team is self-efficient in a true agile manner to notice and fix such habits.

How the product owner is playing or not playing the part during Sprint?

1. The product owner is absent most of the times and questions are getting unanswered.
2. The product owner keeps changing Sprint backlog items; e.g. changing acceptance criteria after the team accepted the user story, increasing the scope of a user story in the current sprint. Once the product backlog item goes to the sprint backlog item, its the responsibility of the development team.
3. The product owner does not agree with new acceptance criteria which is in-line with the new reality. Inflexibility is a direct violation of the scrum core principle.
4. The product owner delays accepting the criteria as soon as the story is done.
5. The product owner does not consult the development team to cancel the Sprint.
6. The product owner does not cancel the Sprint though the goals no longer can be achieved.

How the development team is making Sprinting hard?

1. The team enlarges the tasks of the Sprint without consulting the product owner. The team needs to talk to the product owner frequently.
2. The team is working on the issues which are not visible on the board. This signals massive conflict in the team because the team bypassed return-on-investment, for which the product owner is accountable. It’s worst than the sloppiness and not acceptable.
3. And the usual culprit, the team does not keep the board up-to-date. This deteriorates trust.
4. Every task is a work in progress queue; especially code reviews. The development team does cherry-pick their work instead of delivering the ship-able product.

How scrum master is doing what they should not?

1. Scrum master let micro-management happen. The scrum master is the shield of the team.
2. It’s not a scrum master job to move stories on the board. Also, keeping the boards up-to-date is not their responsibility. The scrum master is missing responsibilities due to this unnecessary lengthy job.
3. Scrum master does not recognize the developer who is struggling to finish the job but does not raise the voice.
4. Scrum master lets the stakeholders disrupt sprint flow. e.g., Management invites engineers to random meetings as SME. Management turns stand-ups to reporting sessions. These impede productivity and scrum master should not let this manifest in team culture.

How stakeholder can disturb the time-boxed commitment?

1. Stakeholder approaches the developer directly for a small task.
2. Stakeholder makes their tasks as a priority task which do not qualify to be on the express lane.
3. Stakeholder invites team members to random meetings.
4. Stakeholder does not attend Sprint review events.
5. Customers do not attend the sprint review.
6. If stakeholders keep changing frequently, they are not able to provide an in-depth review.
7. Stakeholders are passive and disengaged.
8. Stakeholders sign-off the features instead of the product owner.

How management can create a problem in Sprint?

1. Management bypasses the product owner and directly assigns tasks to developers. Management needs to let go of control. Scrum team does not need micromanagement; it’s self-organized.
2. The longevity of a team is essential this helps to build trust between team members. Frequently changing team member can impact productivity and can hamper scrum to live up to it’s potential.

There are some more for which the scrum team is responsible for.

1. Someone adds a task to the sprint backlog and does not consult the team. Another item of the same size may need to go back to the product backlog. The team needs to decide collectively about the exceptions, no single teammate can add or remove the task.
2. There is no clean-up or hardening sprint but the team decides to go for hardening. The definition of done needs to be revisited. This also indicates that quality assurance is not done by the scrum team.
3. The team delivered Y instead of X because the team does not have an understanding. Lack of QnA with the product owner, missing acceptance criteria, granular user stories, no developer participation in user-tests, etc; these may contribute to failed delivery of X.
4. Capacity planning was not done cautiously and the team over-committed.
5. Sprint outcome is not release-able. There was no urgency to deliver. Decision making, autonomy, and self-organization all are traded for delivery commitment; if this does not happen, the whole idea behind scrum is questioned.

This cannot be the list; there are more; some are unique and some are common. Recognizing the anti-pattern is the first step and alleviation is the next. In the idealistic world, scrum can be implemented in a single-shot. Experts will agree that continuous retrospective and improvement is the key to success.

(P.S. This information does not contain original ideas. This is inspired by Internet reads and my experience with scrum.)