Story points

When working on a project here at Box UK, we tend to make sure that every new sprint has a finite number of stories that are achievable within that time. These stories all have story points estimated against them, with the number of points we bring into a sprint based on the team’s current velocity. For example, if velocity is 40 story points, we try not to bring in stories equating to 60 points.

Makes sense, right?

The deadline

Estimating is a fine art and something we have a keen interest in refining here at Box UK. However, every once in a while there will be a shifting of priorities, a change in scope, a challenging target you must meet, or simply a need to stretch yourself and increase your velocity. We were recently faced with this very scenario when we embarked on a critical phase of a large and complex on-going project.

As soon as we started approaching this phase of the project we got together and worked out a plan to ensure quality would not be compromised at any stage. Of course, if requirements are unrealistic and meeting them will negatively affect quality, then saying no is often a legitimate and correct answer. However, on this project there were a number of solutions available to us to help make it a success. A few of the options suggested were: expanding the development team; de-scoping the requirements; doing overtime; and hiring contractors.

Expanding the development team

This could have been an option, however we didn’t have much scope for moving developers from other teams, and we were also aware that adding developers to a project can actually have a detrimental effect.

De-scoping the requirements

We could speak to the client to see if there were any non-essential requirements that could be postponed to another phase of the project; however we still had to prepare an alternative in case this wasn’t possible.

Doing overtime

Although a valid option, this was an absolute last resort. We don’t expect anyone to have to do extended periods of overtime, and the whole reason we work in sprints using story points and affinity estimation is to avoid this. However, it remained in our back pocket should we need it.

Hiring contractors

Due to the size and complexity of the project, similar to expanding the team with other developers, bringing in contractors for such a tight deadline would probably have a negative effect.

All of the above options are about increasing the velocity of the team by extending capabilities or reducing the workload. The only other option not yet mentioned is: increasing developer productivity.

It sounds so simple. “Need to get more done? Oh if you could just go ahead and be more productive that would be brilliant.” However in reality it doesn’t quite work like that. Every developer I know at Box UK works as productively as they possibly can. They can’t just flip a switch and go up from 100% productivity to 120%; unfortunately, we are not yet robots with a productivity dial. So if developers are already productive, how can we increase productivity? One solution – take away external factors. Go to war.

Introducing the war room

We have an open-plan office. This can be good for open communication and a cross-pollination of technical discussions and ideas. However, it can admittedly also be quite distracting at times, as Jef Claes discusses in his article about the open plan fallacy. It’s surprising how much a small context switch can affect a developer and the huge ramifications it can have on their productivity.

It was mooted that if we could decrease the distractions, we could further increase developer productivity. This saw the birth of the war room.

I had read about war rooms and the benefit they pose for increasing productivity before. At the time we were considering this, we had also coincidentally just had some new rooms built within the office, and it seemed a great opportunity to try out this idea and press ahead with creating our own.

The setup

We were able to quickly turn one of the new spaces into our war room. We set up desks for eight people (seven developers, one tester) and off we went. So we had our physical space; we now needed to look at the tasks in hand.

The first step we took was to identify all the tasks that needed to be done, write them on to post-its, story point them, and erect a physical Kanban board to track our progress. We use JIRA for all our projects and it’s terrific software, but for this we wanted to forgo the setup time involved with that and needed a nice, quick-fire way to track project tasks – essentially moving along the post-its through the workflow on the board.

We also created some other boards to track story points and the progress of a few other concepts, and chucked in a few whiteboards for collaborating on ideas.

Once everything was ready to go we had a brief planning session, so everyone knew what they were working on, and got to work.

How it went

From the first day you could see results. The symbolic nature of being in a dedicated room forced people to think twice before asking for a ‘quick meeting’. There was a little window on the door into our room and sometimes in the corner of your eye you would catch someone look through the window and then walk away when they could see we were all busy. The benefits were numerous:

It bred productivity. It was obvious, just from the atmosphere and the tickets getting closed how much more productive people were. Our velocity increased by 37% in the first week alone.

It increased morale. Despite a number of smaller deadlines, the main project we’re working on is a very long-running one spanning a number of years. A change of pace and environment gave everyone a boost. We also had a few new members of the team who initially were a bit unsure about being moved into a war room, but within a few days were really happy and enthusiastic about both the room and the project.

It improved communication. Although previously we’d had daily stand-ups and a constant stream of communication on our internal HipChat channel, communication among the team was not perfect. Everyone being in the same room and focusing on a single target definitely improved this. People were more inclined to get everyone together to go over a particular problem or task around a whiteboard. There was no reason this couldn’t have happened before, but it would have involved an email or HipChat alert to get everyone to spare a few minutes. Now we just needed to ask people in the room if they could have a look at the whiteboard behind them. A small difference perhaps, but it all helps when seeking increased productivity.

We all became fat. Ok, not distinctly true, but the sense of community and togetherness heightened our purchasing of cakes for the team. This had only one outcome on our waistline :)

On a serious note, this subtle feeling of togetherness and an ‘in it together’ attitude had a definite positive outcome on achieving our goals.

The results

We were admittedly expecting positive results, as we couldn’t see any way how it could have a detrimental effect, but we were still pleasantly surprised with how well it actually worked out.

We met our target, increased knowledge of the project, became closer as a team and had already started planning for the next phase of work off the back of the positive and constructive conversations we had while in the room.

So impressed with the outcome was everyone across the organisation, there has even been talk of in investing in more war rooms, or at least making more use of such a setup.


When faced with a situation where you need to try and increase productivity, I would wholeheartedly recommend giving the war room approach a try. We found having the entire team together in a room with a defined target really helped us focus on and achieve our goals.

Some of the most important results we experienced were:

  • Fewer distractions
  • More focus
  • Greater togetherness
  • Improved morale
  • Increased creativity
  • Better sharing of knowledge

Want to hit that target? Go to war.

About the author

Ian Jenkins

Ian Jenkins

Ian Jenkins is a Principal Developer at Box UK. Ian works mostly with PHP, but loves trying out new things. When not sat in front of a computer, he likes to read, watch films and follow sport. Ian thinks he is the only blog contributor who does not play the guitar.

Related content

We're hiring. Let's talk. View available roles