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.
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.
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.