By observing the behaviors of some teams I’ve been part of, I noticed many patterns that held them back from becoming more productive. Many of those teams would use Scrum, which allowed me to learn about the pitfalls that Scrum teams may face.
In this post, I’ll be sharing them with you so that you may learn from the mistakes of others instead of making them yourself. “Wait, what… Scrum?” — If you are new to this universe, I suggest you read What is Scrum? first.
How to read this text?
(!) Keep in mind that I’ll be discussing pitfalls. Make sure NOT to adopt any of the behaviors or strategies described below, except for the #tips.
Planning meeting
Here, the purpose is to connect everyone with the business problem to be solved, besides raising awareness on which metrics we can improve on. It’s about detailing what to do and how.
Want help to take a leap and build a roadmap for your planning meeting? Learn more about building a roadmap here.
Getting to this point without a clear sprint goal
#tip There are three forms of defining a sprint goal:
- The PO arrives with an idea for a goal, the team collaborates and, together, a sprint goal is set. This happens when the team has a good business perspective.
- The PO arrives with a sprint goal, and the team just accepts it.
- The team pulls the backlog items and picks the goal. In this case, it’s a lot like “shooting targets” and killing open points.
Having a task list as a sprint goal
#tip The goal needs to deliver value to the client. If your team does “X,” what will the result for your client be? This should be the purpose.
Having more than one goal
#tip If you have more than one, at least establish priorities.
The purpose must be to deliver stories to the clients instead of value
“Wrapping up the ‘XYZ story‘ will provide independence for the client,” instead of “granting independence to the client on the act of purchase.”
Score bugs
#tip Normally, bugs are a technical debt and need to be solved regardless of the score. Besides, there is a change in the team’s natural behavior when it chooses to overlook quality and fix things later.
“We’ll score the issues later and push them into the sprint.” And then comes the moment of the bug resolution sprint.
Example:
- The team scores the item as being worth 13 points;
- 1 day left until the end of the sprint, and the team decides to wrap up that item with “2 known bugs”.
- In the next sprint, the team scores the bugs as being worth 5 and 3 points, respectively.
What are the consequences?
- The item’s actual cost was 20 points.
- Since “everything is fine” and “the team is delivering,” the team does not become aware of its poor time appraisal capability and, thus, does not improve on setting estimates.
- The team gets used to delivering faulty products and scoring items later, failing at providing value to the client.
- Ultimately, bugs are not deemed priorities, being considered backlog items just like any other, and not a technical debt.
- Eventually, the team finds itself in an unpleasant situation: bug sprints, apps which are too hard to maintain, etc.
Guaranteeing that the team will fix bugs regardless of scoring makes the team feel “penalized” for allowing a bug to slide by.
Such a habit reinforces positive behavior in the sense of establishing extremely low tolerance towards bugs and effectively taking responsibility for quality. The solution is to reinforce the usage of DoD.
The team only becomes aware of the backlog during the planning meeting
#tip The PO backlog needs to be available for the team to access at any moment. This allows the team to see what lies ahead of them and provide help as needed.
Daily meeting
Here, the goal is to coordinate efforts to reach the sprint’s target.
Ask the 3 questions (What did I do yesterday? What will I do today? Is there anything stopping me?)
#tip <controversial opinion!> This leads to a natural status report. If I wanted to know what I did yesterday, I should check the board. If I want to know what someone else is doing, I should check the board.
If anything is stopping me, I should have warned as soon as this impediment first happened! (“Oh, but I don’t always update my board” – That’s another problem, right?) </controversial opinion>
The board is only updated at the daily meeting
Is your board only updated at the daily meeting??? This means that, throughout every other working moment of the day, your team will be subjected to lack of coordination, rework, and lack of visibility?
#tip Update your board as close to real-time happenings as possible.
Not getting started with the sprint goal
#tip Remind ourselves daily about the goal of the sprint and ask if anyone needs help in reaching it.
I suggest you start the day with a Confidence Chart. Then, create actions for the day so that your team will feel more confident in reaching the sprint goal.
The PO says what the team must do
This interferes with the team’s self-organization.
#tip Keep in mind that the development team is self-organized.
Reading suggestion: brush up on the role of a PO.
The SM says what the team must do
This interferes with the team’s self-organization.
Reading suggestion: brush up on the role of an SM.
Holding the daily meeting for the PO
It becomes a status report and reinforces hierarchy (something that shouldn’t exist between the PO and the team).
Holding the daily meeting for the SM
It becomes a status report and reinforces hierarchy (something that shouldn’t exist between the SM and the team).
Review meeting
Here, the goal is to gather feedback on the evolution of the product/service and determine whether we are on the right track.
Not having the client (end-user of the product/service) in the review meeting
#tip, I like to compare this situation to “code in production.” Our goal is to have the code in production, not under homologation, in the development environment, or in the local machine.
This type of reasoning works for review meetings and receiving feedback. It should first come from the end client (production), not from stakeholders and management (homologation), not from other teams (development), and not from the PO (local machine).
Disclaimer alert!!! Holding review meetings for the PO is the worst possible scenario. I strongly advise against it, as it would be like having the code only in your local machine. If the PO has to wait for the review meeting to know what is going on, this person hasn’t been doing their job right.
The PO does not take note of feedback
#tip Dear PO, this is the very purpose of this ceremony.
The PO does not announce the sprint goal and the strategy
Not allowing the development team to show what they built
#tip The team must show what they did, as it raises engagement and will to belong.
Retrospective meeting
Here, the goal is to see how we can improve as a team, generally speaking.
Not holding retrospective meetings for “lack of time”
Holding the retrospective meeting after the planning meeting
It seems evident that the retrospective should come before the next planning meeting, right? But I’ve seen many teams holding retrospective meetings *after* the planning meeting. What’s the point in that?
#tip Apply the improvements of the last sprint in the next planning meeting. This is only possible if you hold a retrospective meeting first.
Lacking action plans or having too many of them
Focus on a few action plans, preferably those tackling pain points.
#tip if your action plans are things you do once and “you’re done + successful,” then fine. However, if those are items that you need to repeat regularly, consider adding them to the team’s agreement. Also, make sure to have a team’s agreement.
Keep having the same retrospective over and over
Lacking a clear goal at the retrospective meeting
#tip Dear Scrum Masters, you need to build or run a retrospective focused on the team’s problem that you intend to solve. How to do it will be a team decision.
The retrospective, however, is the planning meeting for the SM. At the planning meeting, the PO gets there with the problem pertaining to a product/service that the team must fix. The team works on how to do it.
During the retrospective, the SM brings over the team problem that (s)he wants to solve by using group dynamics. Highlighting the problem isn’t really necessary: let the activity do that for you. Once again, the team will work on how to make the magic happen.
Not updating the Definition of Ready (DoR)
#tip Use this question: “What should have been clear and wasn’t, and would have allowed us to deliver properly?”
A possible answer would be: “Oh, if we had known which spreadsheets to access, we wouldn’t have wasted so much time looking for them and would thus have managed to deliver.”
Great! There you have, a new item for your DoR: all necessary spreadsheets must be defined beforehand.
Refinement meeting
The goal is to raise problems, needs, opportunities, and metrics, as well as prepare the items for the team.
<controversial opinion> This should be an official event, already. </ controversial opinion>
Business
Lack of clients and stakeholders
Lack of clarity on the problem to be solved
The PO manages business refinement all alone
#tip Yes, someone else from the development team should be here, figuring out the business together with the PO.
Refining extensively, attempting to cover every single micro-detail
Lacking business metrics associated with backlog items
#tip Generally speaking, the business alignment allows the PO and the team to better understand the demand before creating it, besides aligning expectations from clients, stakeholders, and the development team.
Technical aspects
Overlooking the DoR
Lacking action plans upon dependencies that will come up
Always doing things with the same person
We want everyone from the team to be engaged with technical dependencies and know how to fix them. Here, the idea is to avoid high dependence on technical knowledge held only by 1 or 2 team members.
#tip Technical refinement enables dependence and risk mitigation before the sprint. If you leave this to the planning meeting, it will be too late. The team won’t have enough time to handle any impediments.
Having a good DoR and taking it into account during the technical refinement helps make the work more fluid during the sprint.
DoD
Here, the goal is to ensure quality.
The list is too superficial
#tip Try and make everything as explicit as possible. For instance, instead of writing “Information Safety OK,” try “OWASP top 10 vulnerabilities covered”.
Not taking into account the team scenario
Behaving in a “top-down” manner
I understand that, for many scenarios, the organization has normative and compliance-related needs. It is acceptable that those are replicated to the teams via DoD, but they can’t be all there is to it.
#tip The team needs to list the items that they believe make sense for guaranteeing quality in their respective contexts.
Ignoring DoD when you move an item to “Done.”
Not updating tasks
DoR
Here, the goal is to mitigate risks for the sprint.
The list is too superficial
#tip It must be specific. Avoid things such as “The team gets the story.” Does it, really? Or doubts will arise mid-sprint?
Use things such as “Map all fields that will be used,” or “Is there a need to create APIs, yes or no?” and other specific features of your work routines.
Not using it for technical refinement
Not updating the DoR at the retrospective meeting, when needed
Being too radical with the items on the list
#tip Keep in mind that the items on this list are explicitly trade-offs about the risk. If the item you are letting go may generate low risk for the sprint, maybe it is acceptable not to follow it.
Are there loopholes or pitfalls missing in this list? Leave a comment, and let’s chat about it!
