Scrum, Features And Back? Again

If you've worked on any software development project in the last few years then the chances are you've worked in either a scrum team, on a kanban board or any variation of the two.

Over the past year I've been working in a remote-first distributed team that adopts agile methodologies as part of our daily process, this is our story...

September 2016

Around September 2016 the project kicked off with a team of 4 developers mixed between front-end and back-end programmers, we made the decision to follow a lot of the scrum processes to ensure a collaborative working environment.

We started with two week sprints, at the beginning of which we had a retrospective for the previous sprint and planned our next two week iteration. All the while we were ironing out the kinks of working in a distributed team for the first time.

Scrum was working well for us for quite a while, we got our projects bootstrapped, had quite a few very positive sprints with the odd issue being resolved as part of our retrospective.

That's not to say all of our problems were solved, we probably spent more time than was recommended discussing and testing tools to make the management of our issues easier, we eventually settled on Gitlab issues with milestones for sprints.

February-March 2017 (roughly)

Fast-forward 5 months and we've got our projects bootstrapped and well into the feature development phase, this is when we started to find some limitations to scrum for our team.

We knew we had to complete a certain set of issues to complete a feature that we'd try to focus on in each of our sprints, but we reached a stage when the availability of the team was fragmented with some members having a lot more time than others. This meant that our front-end and back-end were suddenly out-of-sync.

With this it became more and more difficult to pick a single feature to focus on for a sprint; more of our sprints were resulting in a feeling of dejection due to less work being achieved than was hoped for.

We were also only using sprints to time-box work, so why not try something new?

Feature Driven development

At this point we decided to get rid of our sprints and backlog milestones in Gitlab and streamline our issues into the feature milestones.

This was great and gave us an idea of how close a specific feature was to completion through the number of issues still to be completed, it didn't matter whether they were in a worker service, the API layer or the front-end web application, we could see at a glance how close we were to releasing a new feature.

What did we discover?

While everyone was enthusiastic for this change and thought it made a lot of sense for our use-case, especially with the differences in available time, we found that very little work was being done.

I couldn't tell you why this was; it appeared that for our team working without the time boxed constraint of a sprint meant we just didn't focus on what needed to be done and devote the time that we needed to.


After our attempts at going down the Feature Driven Development route we're back to working in a more scrum-like system. We have weekly catch-ups and retrospectives, people post a daily standup on Slack and we try to identify blockers as early as possible.

We've found a system that works for us and obviously YMMV, I'd like to try Feature Driven Development again, maybe if this was something we were doing full time rather than in our evenings and weekends. But if you have been part of a team that's done Feature Driven Development well, I'd love to hear from you the benefits and challenges that you faced.

Categories: agile, project management, scrum