Introducing SCRUM - ideas for a process backlog

4 minute read

In a recent project, I had to bootstrap a SCRUM environment – so the question is where do you start? One way of course is to get everybody on a SCRUM training, then setting up some infrastructure, and then start. I had this luxury at a previous company in pre-SCRUM era, but this time a more agile approach was needed. We had a project pipeline which was more than full and had to deliver while in transition towards SCRUM. So the idea was to introduce SCRUM incrementally – after all this is what SCRUM is about.

So, what can you actually achieve in terms of implementing SCRUM in your first sprint if the situation is not in your favour? You have a distributed team? Command and Control culture? Not one product manager but a board of 15 with no single shared view? And maybe more…

Well, it is not realistic to do everything at the start. And also, you will need some success stories along the way to sell the idea both internally in the team and outside to management and other stakeholders. One way is to look at short term benefits with each single change. Starts to sound like the devlopment of the product itself. So why not build your “process backlog” to prioritize and schedule.

The process backlog

On this “process backlog” you could put all SCRUM practices like creating a product backlog, using timeboxed sprints, having daily scrum meetings, etc. And you could also add supporting practices like setting up a continuous integration environment, among others. Some of these may be from the XP world, but it really depends on your situation.

Then you pick items from this list for implementation in the upcoming sprint. As soon as the sprint retrospective is implemented (may be at the end of sprint 1) this is a natural place to look at process items to pick and implement.

Story 1: timeboxed sprints

The easiest sell in my experience was the concept of a timeboxed sprint – it gives the customer the assurance of a timeline and the price (possible de-scoping) is not so visible at first. There will be fights about this later towards end of the sprint, but it is still reasonably easy to sell the idea. If you must, you just implement monthly project reviews and go through the agenda for the end of Sprint demo without telling too much theory. Once they start to like this idea you tell them what SCRUM says about it. (Actually this is another great idea I got from Henrik Knibergs great book [Scrum and XP from the Trenches] ( and I wish I had known this earlier)

Story 2: daily scrum

Also, the daily scrum meeting was a point at the start. In the beginning it did not feel like a “self organizing team”, more like traditional top-down micromanagement. Still better than no communication at all, but geographical distribution and cultural gaps in the team have made it difficult to get to a more collaborative approach quickly. So the meeting had to be done on the phone actually because we wanted to keep the ceremony low. Just thinking of getting everybody into a video conferencing room (and booking this rooms in both facilities in advance) was not something I wanted to tackle in the first sprint.

Story 3: sprint backlog

Then there was the sprint backlog – in its almost simplest form of an excel spreadsheet. A real task board was not the right start for us because the team was in different continents. It would be great to have a better tool support for this but this was out of sope for the first sprint. I am toying around with Sharepoint wiki’s because it was available, and this could be a next step. The goal would be to build more a visual and collaborative experience for all team members to get them “hooked”.


This was about as much as we achieved in the first sprint – after all we basically have put this into a team used to less agile ways of working and we couldn’t invest too much time in process changes, tools or training. All of the process investment has to be incremental over time. The plan would be to address the product owner problem next and make sure we have one product owner to be a single point of contact, and this one would need the authority to prioritize and the acessibility that the team can actually use her as a knowledge source. Once we have someone to own the product backlog, this needs to be implemented next.

This was the experience from the start, I will later write a followup to keep you up to date.

Thanks for reading, and I do hope that these ideas are useful.