We've recently had a specific piece of work come up which we thought was ripe for trying with Scrum. The simple headline of the project was "Re-brand the website to the new group brand". There were a number of reasons we thought it worth using scrum again:
- The project had a pretty well defined scope
- The level of complexity was low, with few unknowns
- The deadline was relatively close (2~3 months)
- We wanted to try Scrum again, to test our thinking on our process
Creating the New Backlog
Working with the Product Owner, we produce a product backlog
for the rebrand pretty quickly. It had
around 60 stories in it. With a couple
of people from the team, we quickly reviewed these, looking for the following:
·
Areas of complexity and /or technical risk
·
Logical dependencies (does it make sense to do
Story A before Story B) [see below]
·
High level “T-shirt size” estimates
For around 60 stories, this was relatively easy to do. We prioritised the stories that were complex,
large or otherwise made sense to do sooner rather than later, and took them to
sprint planning.
Story Dependencies
I should probably do an aside on story dependencies here,
before someone jumps on me. I know that
stories are really meant to be independent and shippable alone or in any
combination. This is a worthwhile ideal,
and something that we strive towards.
However, it’s just not always possible.
Particularly in this project - we wouldn’t ship, say, a rebranded header
without the rest of the site being rebranded – in fact, the whole rebranded
site will ship as a single release, tied in with other activity (customer communications,
etc). However, we have been releasing
internally ‘work in progress’ versions of the site for other stakeholders to view
and comment on.
However, that doesn’t get away from my general view on story
dependencies. As I said, while independence is a worthwhile idea, sometimes it
just makes more sense to do one story before another e.g. story A might require some underlying software
architecture or infrastructure work which other stories also need.
Sprint Planning for Sprint 1
I was nervous about our first sprint planning meeting,
bearing in mind how terrible these were previously. We took the prioritised backlog in, and
starting discussing the stories. While
some of the old issues raised their heads, because of the relatively low level
of technical risk and unknowns, people were able to generally agree on the
points for each story without the endless discussions around implementation
detail. I think we got out of there in
less than 2 hours, and with 7 stories worth 20 points for Sprint 1. While this proposed velocity wouldn’t get the
whole backlog done by the time we needed to ship the rebranded site, I wasn’t
too worried as I knew that we’d front-loaded this sprint with the bigger and
riskier stories.
What had we missed from Scrum?
Going back to Scrum definitely reminded us of some of the
great things that we’d missed. The short
sprint deadline (we use 2 week sprints) definitely brings a degree of focus to
the team that maybe we’d lost. Sprint 1 went well, but in the process made me
think about some of the things we liked from Kanban.
What did we miss from Kanban
As Sprint 1 progressed well, it looked like we’d
over-estimated a couple of stories, and we wanted to pull some extra stories
from the backlog. Normally this is a
no-no in Scrum, but from our previous Kanban experience, we weren’t worried
about doing this. We did set some basic
rules – if a dev wanted to pick up a new story, they had to first check that
there was no help (including testing) that they could offer on any existing
stories in the sprint. They also had to
be confident that the new story could also be completed in the current sprint.
As the Project Progresses
We’re now at the end of sprint 3, and things are still going
well. Our decision to put the
difficult/risky /technical stuff in the first two sprints has paid dividends,
and the remaining work is getting simpler and simpler. Sprint planning for Sprint 3 was particularly
straightforward.
The constrained scope and low level of unknowns has meant
that our analysts on the team are under-employed, however – most of the stories
are so straightforward that a dev can often immediately start coding. It’s this
lack of complexity which I think is key to our success on this project with
Scrum.
What Next?
For the characteristics outlined above, Scrum works well for
us. Or, perhaps, it’s just easier to do.
The stories are relatively homogenous, within a nicely constrained and defined
scope, and with little analysis required.
Once we’ve delivered this rebrand, I expect to go back to
Kanban. I still think it works better
when you have a range of heterogeneous stories, some with real complexity
requiring analysis, and optionality on scope and release.
