While preparing an introductory workshop on Scrum, we wanted to end our sections of presentation/retrospective with some general tips on the area discussed that would give a team that is starting out with scrum some help on things to try. And things better not to try.
I mean, Inspect and Adapt, yes, but it won’t hurt to avoid some common pitfalls.
Here’s the things we came up with, please let me know (below or on twitter) which ones you don’t agree with, and what important ones we missed!
Try: Making stories small enough to be DONE within three days
Smaller also means easier to estimate, and easier to test. One of the most common things I find is Really Big User Stories. That makes everything hard.
Avoid: Working on less important stories before finishing more important ones
(De-)Prioritise ruthlessly before taking things into a sprint. During the sprint, don’t work on lower priority issues before the higher priority ones are done.
Try: Splitting stories vertically
If every story has a user facing component, (de-)prioritising parts of functionality becomes possibly. The earlier the user/customer can see the functionality, the sooner you can get feedback.
Avoid: Splitting stories by component
Delays getting feedback. Encourages work not directly related to functionality.
Try: Making stories specific by defining acceptance criteria for each one
You’ll know better what to do, how to estimate, how to test. And when you’ll be done.
Avoid: Making stories too detailed too early
You’ll add detail to stories in the course of the project, but doing it too early can mean
- working on something that’s not going to be used (in a while),
- doing work that will need re-doing (once the customer sees the initial work, he will change his mind),
- skewing your estimates: too much detail can inflate estimates beyond any realistic values.
Try: Estimating your complete release backlog with the full team
The whole team will gain understanding of what is expected. You’ll get better estimates. You can use a release burndown!
Of course, there are things that can help with this such as, ahum, having a clear vision, but you need to start somewhere.
Avoid: Not updating your estimates as you learn more
Estimates are estimates based on current understanding. If understanding doesn’t evolve during work, something is wrong. So estimates should also evolve. As you refine and split user stories, re-estimate them to evolve your planning along with your requirements.
Try: Fixed sprint length (of two weeks)
Fixed, for predictability, letting the team find a rhythm, ensuring problems (waste!) get raised. Two weeks, because one week is initially difficult for a team to do (but if you think you can, please try it!).
Avoid: Telling the team how much to take into sprint
You can’t expect a team to take responsibility for delivering if they don’t have control.
Try: Many (min. 6 – 10) small stories in a sprint
Failure to deliver the last story is much worse if it’s the only one. Or one of two. Smaller also means easier to estimate, and easier to test. It’s much easier to determine progress if you’re talking about ‘done’ stories, instead of percentages. (that was sarcasm, probably.)
Avoid: Stories that span multiple sprints
Try: Counting unplanned issues picked up in a sprint
If you get a lot of unplanned issues, you need to take that into account in your sprint planning. Count to get an idea of how much time you need to reserve for this!
Picking up all unplanned issues raised during a sprint
The PO should de-prioritise anything that is not a crucial customer problem, and then put them on the backlog to be planned in later sprints.
Try: Reserving a fixed amount of time (buffer) per sprint for unplanned issues
Measure how much time you’re spending on unplanned issues. Reserve that time for them (so your planned velocity goes down), and work on Structural fixes so this time reservation can go down in the future (after you measure you don’t need all of it).
Avoid: Extending buffer for unplanned issues
Because the buffer is there for a reason. To make sure that the rest
of your time can be spent on what you’ve taken into the sprint. One way to deal with the buffer thing (to avoid getting tangled in time percentage calculations) is to have a rotating role in the team that deals with issues that come up. Call him Mr. Wolf
, if you like, because it usually isn’t the most coveted role to play. That’s why you rotate…
Try: Highly visible display of sprint & release burndowns in the team area
Highly visible progress helps keeping focus. Whole team can see (and can feel responsible for) progress. And mostly, this is a great way to discuss any upcoming new issues with whoever is raising them: “Yes, I can see that this is important to you. Let’s look at what we’re working on right now, and what we need to delay to get that in…”
Avoid: Only updating a computerised issue tracker when completing tasks or stories
A physical task board provides continuous visibility and feedback. Seeing people moving things on a physical task board during the day simply encourages getting things done. Putting a post-it on a wall simply feels more real than putting a new issue into JIRA. There are so many ways in which the visible and physical are wired into our system, that there really is no way to replace that with a computerized tool.
Try: Taking turns during stand-up by passing a token
Sometimes stand-ups can devolve into a rote, going round, reporting status form. Break this by passing/throwing a token from one speaker to the next, in a self chosen order. This keeps things lively, avoids anyone dominating the stand-up, and makes people pay attention (or drop the ball:-).
Avoid: Reporting to anyone but the Team during stand-up
At all times avoid the stand-up becoming a ‘reporting to a project manager’ thing!
Try: Having a retrospective at the end of every sprint
The whole idea of Scrum is to continuously improve. You can’t do that if you don’t discuss how things went.
Avoid: Not executing improvement experiments generated in the retrospectives
Don’t just agree you need to improve. Do Something Already! At the end of the retro, agree which points you’re picking up, and ensure they’re taken care of in the next sprint. Also, with your action, try to indicate what the expected result of the action will be. Deciding whether your test was a success will be so much easier. Look into A3 problem solving
when dealing with bigger issues. Or even with smaller ones.
Try: Highly visible display of top 3 impediments
And cross them off one by one as soon as they’re done…
Avoid: Stories that span multiple sprints
Yes. A bit obvious, perhaps, but this is happening often enough that I thought it worth mentioning.
Try: Having an impediment backlog for the team and one for management
Yes, impediments that managements should fix, should be just as visible (maybe even more so!)
Avoid: Having a very long impediment backlog from which no items are ever picked up
Agree what to pick up, don’t pick up too much at once (start with one at a time!), and FINISH them.