Dear Scrum Helpline,
We are now into the third hour of our planning meeting and we’re still trying to figure what’s going to be in the next release, having had only a couple of small breaks.
Some are frustrated, some are quiet and seems from investigation that’s partly because they’re used to the mess hence lost interest I think.
The problem is we’ve got a bunch of bugs that one guy is working on as it’s all part of his code changes. But it’s difficult for others to help out because it’s in one specific area, and now they’re trying to decide if others need to work on them as they’re concerned about whether they’ll get done.
They miss the fact that if I’m working on specific code and know the issues, I can fix better than bringing others in (for example).
QA are getting frustrated (and I understand why) because they’re saying this is a bug but – well I don’t know, it’s just turning into a low key argument (well maybe “argument” is too strong).
We had a discussion previously in the retro. We do NOT and will NOT have BA’s but how do we define what the requirements/acceptance criteria etc
Wait a minute… oh no, the Agile coach has just given up on this call so will have to continue this discussion another time lol.
At my last job we had minimal of this stuff and we worked on things without major issues – here, not so simple. It really is all over the place.
Is this really agile and does it have to be like this?
Response by Ian McGrady, Scrum Master, Wipro:
Dear Friend,
Your team suffers from inadequate backlog refinement. You can’t show up at Sprint Planning with a team that has no ideas if Backlog (BL) Refinement is also failing.
BL Refinement is the engine of Sprint teams. When BL Refinement is inadequate, the team tries Refinement during Sprint Planning, yielding both lousy refinement and lousy planning, as you suffered while you wrote.
If BL refinement is failing your team, loosely speaking, you are failing at both Scrum and just regular old teamwork.
When you read the Scrum Guide (SG) and see what is expected to happen at Sprint Planning, ask yourself: what do you need to be ready for such an event?
- Someone to choose a Sprint Goal usually before Sprint Planning.
- Enough Ready work items to select from to meet that goal, having a Definition of Done.
- Someone to prioritize these bugs vs other work.
- A team that is versed in what other options exist.
But now you’ll have to ask why Refinement with the team isn’t happening.
I’m guessing you have someone dominating inspect/adapt by either taking up all the air, or pushing the team away by saying they can handle it themselves and then neglecting their responsibility for a healthy backlog. Neither is good.
The person who cries “there’s no time!” is the person who allows dumpster fires as management.
You also have a fragile team: if the person acting as a constraint quits, the team and product will get stuck.
So:
Go through a cycle of rebuilding this team with the people you have. Have a workflow, working agreement, def of done and def of ready meeting and create artifacts commonly available and updated as needed.
Start pair programming with this team so they can all learn these areas. Let the pairs be slow if necessary: Agility and non-fragile teams are investments.
Respect your time boxes and push to get the advertised value out of the SG.
Run this by the agile coach and whoever else will blow a gasket over time invested in team building. You either grow through this, or you live like this, one way or another, forever.
It’s really Agile if you let the team have contexts for direct honesty and useful conflicts. It’s not Agile if you let things slide without addressing them. It’s never Agile to think awful can’t be improved.