Adapting SCRUM: how we organise our development tracks

profile picture

Bruno Product Service Lines Director

17 May 2017  ·  9 min read


At November Five, we always want to make sure we are able to ship our products as qualitatively and efficiently as possible. In this post, we show you how we manage our development.

Like a lot of development companies, we have been using SCRUM for a while – ever since 2011 to be precise. And we have been working in multiple iterations to improve this process ever since! We work hard to make sure it always lines up exactly with the ever-evolving ambitions and operations of our company.

When we first introduced SCRUM, we had a few goals in mind. First off, we wanted to be very flexible in terms of scope towards the client, allowing for scope changes during the development stage. Secondly, we wanted to be able to ship faster to a production environment to evaluate that what we had created, would be well received by the users of the product.

Over the years, the kinds of products we’ve been working on have changed, from more marketing-driven solutions towards really business-critical tools that require continuous delivery. With this evolution, we’ve also been tweaking our internal workflows.

However, there’s one thing that will never change: each project has a deadline on which we have to deliver great work!

What I want to elaborate on today is a big enhancement we’ve introduced to all of our projects a while back, which we call “sprint overlap”.

But before moving on to that, let me first give you a better insight in our process, and explain why we needed it in the first place.

How does our typical process work?

Typically, when you work in an agile development cycle, a sprint will start on Monday morning and it will probably end on Friday, last day of the week. Whether you work in 1-week, 2-week or even longer sprints, this is the most common setup: it gives closure to the developers and is a good way to start the weekend.

On that final day, you would typically organise a demo with the entire project team to evaluate what was created during the past sprint. You go through the backlog and make sure that what each developer has committed on is being shown during this slot. And you’ll use the time to acknowledge if a story can be approved or needs rework.

To get full closure on the sprint, you’d also already make an estimation of what can be delivered in the next one, and organise a retrospective to allow everyone their say on what went well and what could have been better.

So far so good, right?

Well, actually, not really, because there are a lot of downsides to this way of working.

What seems to be the problem?

Let’s show you a couple of examples of situations we faced in the past – perhaps they will look familiar.

1. Your developers want to show off

Typically, as a project manager, you’ll be tempted to allow your developers to keep working up until five minutes prior to the demo. This way, everyone gets to show off the impressive amount of work they have done during the past sprint – great, right?

Well, not really: the code produced in those final moments before a demo won’t have the same quality as the other code, which will backfire as soon as you start your testing process.

2. Design feedback is not implemented

Because we want to showcase all the features we have created, we don’t always invest enough time on the feedback the designer has given. At this stage, it feels more important to tick off all the stories in the backlog, than to have all the design input tackled – even if the latter is a crucial step.

This will have two very likely results:

  1. We bundle most of the design feedback closer to the end of the project, which potentially means a lot of last-minute UX reworking for the developers. And because the deadlines is looming, there might not be enough time left to fix things properly.
  2. As a result, designers are not really enthusiastic when we push them for feedback – they know many of their remarks won’t be implemented after all.

3. The tester is not involved in the sprints

Before we implemented the sprint overlap, we basically showcased features in the demo that still needed to pass QA. We did this because we saw testing as something you do near the end of development, in a dedicated stabilisation phase. You need a full end-to-end test anyway in order to successfully ship a product, so why invest all the time in advance for something that isn’t ready yet?

You guessed it: this was a mistake. If you’re developing in sprints the whole time, patting yourself on the back for working in an agile way, but then keep the testing phase for the end… you’re basically inching back towards a waterfall methodology again.

What we’ve learned is that doing this puts a lot of weight on your operations and especially on the planning, because if something pops up, your developers will already be scheduled for another project or another release of the same product. In other words, they won’t have the time to implement all the feedback that comes out of the QA process.

The bigger your project becomes, the more heavy the testing load will be and the more impact the testing phase will have on the development team and the other running projects.

4. The Project Manager is tester and designer at the same time

If you work the way we describe it here, you’re putting a lot of weight on your project manager’s shoulders, seeing as (s)he’s the one approving the scope with the client during the sprint setup.

Your PM will be testing the product, to make sure (s)he’s able to give a solid demo, and (s)he will be the one saying that the design has been implemented well enough for the demo.

However, the PM should be the one orchestrating the project: making sure that the designer approves the design that was implemented and allowing a tester to do his work during the sprint phase, all to give a developer the necessary feedback before the demo, and hence to successfully close a story during the demo meeting.

5. Wrong indication of the status of your project

As a result of these factors, we started noticing that the backlog, which we always consider to be the barometer of our project, wasn’t always giving us the right information. Stories were marked green – the color for stories we have delivered successfully and are also validated by the client – while they weren’t completely tested or still had some outstanding design feedback.

All in all, we were delivering good products, but as you can see, there was still some room for improvement.

How did we tackle this?

To make sure that we take enough time to deliver a qualitative product, you first of all need time – it’s your most valuable resource ;)

Quality can’t be rushed.

However, whether you like it or not, projects have deadlines and they always will. So apart from making a rock solid project planning with the scope neatly mapped out, resulting in a setup that offers you enough time, it is also important to make the best use of it.

To successfully do so, we adapted our sprint setup, keeping 2 crucial things in mind:

  1. Development involvement during design sprints
  2. Design and testing involvement during development sprints

The “sprint overlap” is what solves that second problem.

A 2-week sprint setup at November Five

The 2 week setup

During the 2-week sprint we want to make sure that all members of the SCRUM-team have the same information to work as efficiently as possible towards the demo moment.

The typical meeting setup looks like this:

  1. Design kick-off
  2. Grooming sessions
  3. Standups
  4. Development kick-off
  5. Design demo
  6. Development demo
  7. Technical alignment
  8. Sprint planning + retrospective
  9. Sprint overlap day a.k.a Stabilisation day

What happens exactly during the “sprint overlap”?

Let’s say that we have a demo slot booked with the client on Friday, during which we will showcase the result of sprint 1.

The overlap moment starts on Wednesday afternoon and ends on Friday after the demo.

First moment: Sprint planning session

In this session, which takes place on Wednesday, we close the current sprint (sprint 1) and decide what we will deliver in next sprint (sprint 2).

During this meeting, we use our project barometer, our backlog, and focus on one question: is a story 100% ready to be showed during the demo on Friday?

  • If this is the case, we move it to the “ready for test” state in our backlog.
  • If this is not the case, the story will move to sprint 2, meaning it is not in scope for the demo.

In the same session, we also start the sprint planning for sprint 2. We decide which stories we will be able to deliver in the next sprint, taking into account which of the items were not delivered in sprint 1.

This session has a number of goals. First off, the project manager can brief both the tester and designer the day after, meaning much less time is lost and everyone stays up to date. Secondly, the project manager can also start preparing for the demo on Friday immediately, knowing exactly what will be the scope of the next sprint – information he can then share with the client during that demo. And finally, the developers know they can expect feedback from the tester tomorrow, but in the meanwhile they can already start working on sprint 2 – without rushing towards the demo session with last-minute fixes.

Second moment: The stabilisation day

The day between the sprint planning session and the demo is what we call the “stabilisation day”. This extra time serves, firstly, to ensure that the project manager can fully prepare for his demo the next day with the client. It also allows the designer to fully evaluate the current state of the product, focussing on the scope of the sprint, and the tester to entirely validate the scope of the sprint based on his defined test cases.

Third moment: The demo session

The demo meeting at November Five has the purpose to get the client on board of the project team as a full team member. In this session we can clearly showcase what we have created in the previous sprint and we can also inform him of the scope for the next sprint.

Wrapping it up

Remember those five problems we talked about earlier in the article? Let’s recap how each of those is now solved (or at least, handled far more elegantly) with this two-week system.

First off, it keeps one of developers’ and project managers’ peskiest mutually reinforcing habits under control. The system removes the temptation to keep development work going up until five minutes prior to the demo.

Second, it ensure that the responsible designer has approved of the complete delivery, and no feedback is lost.

Third, a two-week approach means that there was enough time to fully test the demoed story.

Fourth, the PM can feel more confident in demo-ing the product to the client, because (s)he can focus on a PMs core tasks – not on last minute testing and design feedback.

And finally, the new way of working ensures that our backlog is always truly up to date!

I’m sure this is not our last step in optimising our process, so stay tuned to get more updates on how we manage our internal processes. Next week, our product ops team will dig deeper into our testing process…