How can you recognize if it is not, and what can you do to improve both your long-term and short-term planning sessions.
The new year is here, and that means two things: vaccine 🙏 and fresh rounds of yearly and quarterly plannings 🤦♂️. We have finally figured the first one, but the planning is a tougher nut to crack. We hear questions like this every single time:
“How do you convert story points to manhours?”
“How many days is an M-sized shirt?”
“Give me a high-level estimate!”
While we have numerous estimation techniques at hand, we struggle with when to use which and how to connect them all together. And with the best of intentions, we usually end up overcomplicating the process…
Learn how to pinpoint your team’s problems using the two weeks long experiment.
This is a description of the experiment from the story “How the COVID outbreak accidentally kickstarted SCRUM in our IT department”.
While I was aware that the experiments like “one day sprint” exists, I had never witnessed it myself before this spring. That is when I found out how powerful short sprints really are. Where week or even two-week sprints often hide the true problems the team faces, short sprints are merciless.
- Are your working hours not overlapping enough?
- Are your tasks not clarified on the planning?
- Are you not committing and merging frequently enough
- Are you spending to much…
This is a story. If you are interested in a step-by-step manual to reproduce the focused sprint experiment, head to my other article.
I am quite biased against all types of SCRUM simulations. I have yet to attend one where the “eureka” moment for developers are be of any long-term significance.
I believe that the problem is the transfer of learnings from the small controlled environment to the day-to-day life in the workplace. This is especially evident when the team is already working in some “dark scrum”, “scrum but” waterfall-ish workflow.
“Yeah, we saw how quick the stand-up was, but…
Ditch that boring meeting! The closer look on some common anti-patterns of the backlog refinement based on my observations.
I have observed this pattern in several SCRUM teams. In all team member’s calendars, somewhere in the second half of the sprint, there is a big solid block. Usually, it’s a one or two-hour-long meeting called “Backlog refinement”, “Backlog grooming” or something like that.
And if you have a chance to join this meeting, within 20 minutes after it starts you can see team members occasionally peeping on their phone screens. And towards the end, only one or two members + product owner are actively participating in the meeting while the rest has more important things to do.
More honest…
