Agile for Agencies - April 2014

After a dry 2013 we had our first agile for agencies of 2014 and it was a real success. 

M&C Saatchi provided great hospitality, a brilliant room with integrated screen and clicker, spacious room with comfy seats and loads of beers and pizza, we were off to a great start!

First up was Tariq Khan (Head of Project Management at TMW) who shared his thoughts and advice in order to run successful agile projects in an agency. His talk was popular and triggered many questions from the audience, you can check out his slides here:

Then Leanne Page (Project Manager at M&C Saatchi) talked about her experience and learnings from an agile transformation in a previous company and how they can be applied to the agency model. She shared great insights and tips for managers and leaders on how to approach an agile implementation in agencies, her slides can be viewed here:

John Bown (Operations Director at Aqueduct) stepped in for Lee Cook who had to rush to Manchester at short notice. John shared his thoughts on the problem with fixed price estimates and how to sell in sprint based pricing and contracts to clients. His tips and real life agency stories got the audience going and triggered laughs as well as many questions. 
John’s slides are not yet available but we will share them as soon as they are uploaded.

From our point of view the event was a success and we were encouraged by the many positive comments we had after the event.

We plan to run it more frequently this year so if you are interested in sharing thoughts and tips on running agile projects in agencies or simply host the event for free please get in touch with Guillaume (@theg) or John (@johnnybown).

Explaining the 50/90 estimation technique option in easyBacklog

easyBacklog provides two ways of building estimates.  Either you can use the single number estimation technique where the number of points are simply added up to create your estimate, or you can use the 50/90 contingency buffer estimating technique.  

The contingency buffer is automatically calculated using a proposition as described in Chapter 17 of Mike Cohn’s book Agile Estimating and Planning. For each deliverable we provide two figures, a realistic estimate and a worst case estimate

In this approach, our “realistic” estimate is the value at which we have a 50% chance of the task taking longer than the estimate, and a 50% chance of the task taking less than the estimate. If the distribution were symmetrical (unfortunately, it’s not), this would be the midpoint. A useful, but slightly inaccurate way of thinking of this is as the “most likely” case estimate. The “high” estimate is the value at which we have a 90% chance of completing the work in less time. Making the 90% estimate requires either a lot of confidence and knowledge, or a really high estimate. On a task of high variability or unknown elements, the spread between “realistic” (50%) and “worst case” (90%) can be quite large.
From this figure we will calculate a contingency buffer where the buffer is calculated as 

Please note that this explanation was taken from Idalko

Scrum and XP from the Trenches review

One of our members suggested we read the great hands-on practical scrum guide written by Henrik Kniberg titled “Scrum and XP from the Trenches”.  It’s a free eBook, and can be found at

Here is what we thought of the book in the context of easyBacklog and the features it provides to help implementing an Agile methodology with your teams.  Please note, many sections within the eBook are left out in the review below, we have cherry picked the sections we felt relevant to easyBacklog and backlog management.

Practical advice

The book does not theorise about how Scrum and Agile can be implemented in teams, it’s very much a hands-on guide describing Henrik’s experience implementing these methodologies at the company Crisp where he works.  As such, it’s important to bear in mind that whilst his experience is extremely valuable and we can all learn from, his experience very much pertains to his environment, his team, and his own preferences.  Saying that, we found his preferred way of implementing Agile and Scrum very sensible, and mostly in line with how we have been implementing Agile with theeasyBacklog beta testers.

Section: How we do product backlogs

There really isn’t much to say about product backlogs as they are pretty straightforward.  Henrik does cover how to deal with producte owners who create stories that don’t solve a business problem, but instead describe functionality such as “Add index to table”.  

It’s interesting to see that Henrik deviates from the recommended format for a story of “As a”, “I want to”, “So I can” prefixes.  We can see the relative pros and cons of more flexibility versus sticking to a tried and tested format, however we have opted to stick to the “As a <role>, I want <goal/desire> so that <benefit>” format as it ensures consistency for each story and everyone can look at a story and understand the scope and business reasons for each story.  

Henrik advocates the use of a shared spreadsheet over existing agile tools primarily because of speed i.e. simply entering values into a cell is faster than other agile software tools available.  easyBacklog has focussed on addressing that exact issue, speed and flexibility.  As such, we’ve now replaced all of our spreadsheets by using easyBacklog instead as it is now faster.  We differ from other agile tools in that all fields are editable in a spreadsheet like view, and all editing is available through keyboard access i.e. using Tab/Shift-Tab to move forwards and backwards between fields, stories or themes.  We find the tool so fast that Scrum Master / Project Managers typically goto meetings with the product owner to draft an initial estimate directly within easyBackl

Note: Currently we don’t support the importance field, but do allow color coding of stories so you can “code” the importance easily using your own coloring system.  We’d like to hear from people whether the importance field is something you need?  If so, we’d certainly consider adding it as a core feature or possibly an option for backlogs.

View an example screenshot of the backlog interface »

Sections: Sprint Planning

Henrik is very clear that real world interactions and physical boards and cards is preferable over software tools.  When it comes to sprint planning, he advocates product owners being involved, and using physical story cards that are shifted around by everyone involved, thus ensuring everyone feels like they are participating.  He talks about their experience of trying to use a projector and a backlog management tool controlled by a single person, and his experience indicates that this does not work because it’s really restrictive and that single person becomes a bottleneck very quickly.   And finally he talks about the justifying why a product owner needs to be involved in the sprint planning meetings because only he/she is in a position to confirm scope, requirements and importance of each story, something that is often lost on a story card by itself.

easyBacklog is very much compatible with the methodologies that Henrik outlines for sprint planning.  Story cards can be printed out prior to the planning meeting quickly, and all the stories can be assigned to a sprint easily from within easyBacklog once the team has agreed what will be completed in the next sprint. It is important to remember that whilst some of our users have been providing the Agile teams with access to easyBacklog, easyBacklog is a tool designed for product owners, project managers and scrum masters.  Thus, during sprint planning, we don’t expect anyone  in the Agile team to be using the tool, we’d expect them to be looking at the physical cards, adding tasks, estimating and focussing on the board.  The Scrum Master on the other hand would possibly be updating the status of the sprint from within easyBacklog, or possibly retrospectively udpate the sprint once the planning session is completed.

An interesting idea that Henrik suggests is that each Sprint should have a goal that is communicable to the team and stakeholders.  We currently don’t support this concept, and do not think it is necessary as this tool is not meant for the broader team to use.  These goals would be written up on the board and distributed to the team.  Saying that, we’d be open to hear from our users as to whether a Sprint wiki or something similar would be beneficial to you and your team?

During sprint planning, it seems that it is quite common for teams to split larger stories into smaller ones.  We currently don’t support splitting stories (this can be done with Duplicate, but this is not quite the same).  We’d love to hear from our users if this is something that would be of interest to you, or if this is really an edge case bit of functionality?

Henrik also talks about man days and focus factor; focus factor being a percentage representing the efficiency of the team in terms of what it can deliver.  He indicates that typically his teams would have a focus factor of 70% meaning for every 10 man days, they would on average complete 7 days of work.  The focus factor is effected by people being sick, impediments, efficiency of the team, and distractrions such as bug fixing or support.  With easyBacklog, we tackle focus factor in a different way.  Because we use story points as an estimation of complexity for a story, these points may or may not correlate with man days depending on how your teams estimate stories.  However, what this represents in terms of time is really irrelevant, all you need to know is how many points a team typically produces each sprint, and divide that by the number of days in a sprint.  So for example, we have a team of 2 developers producing 100 points of work every 10 working days, this would mean that their average daily velocity is 5 points per day (100 points / 10 days / 2 developers).  Each team will have a good idea of what they’re achieving, and this estimate of points achievable per day per team member will help you with estimating total project cost / duration based on the points in the estimate.

Henrik advocates that developers / agile team members break down stories into tasks.  As easyBacklog is aimed at Scrum Masters / Product Owners, we intentionally don’t offer this functionality.  Tasks are typically defined in the sprint planning process and are used by the team to agree on the scope of a story, and what is involved at a more granular level.  This information does not need to be added back into your backlog, all that is important are the number of points required to deliver that story from a backlog management perspective.  Those tasks need to live on the task board, be visible and then be used to monitor the progress of a team to deliver a story.

Sub-section: Bug tracking vs product backlog

Finding a solution for this has always been perplexing for us because there are so many ways to address this problem.  It appears that Henrik too has not yet found a single way of approaching this and suggests four approaches:

  • JIRA is kept separate from the backlog management, but at sprint planning meetings these bugs are presented on the board and can be included in the next sprint as new stories.
  • Product owner creates stories for each bug directly in the backlog
  • Bug fixing is not considered part of the sprint, thus this is factored in to the velocity calculations i.e. we have found a team member typically delivers 4 points of functionality a day whilst at the same time spending around 1 hour per day on bug fixing.
  • Have a single backlog / bug tracking system that treats everything as equal importance.

Henrik says that option 1 is his preferred choice, but he does find each team has their own style.  With easyBacklog, because we are focussed on providing a tool that helps with “fixed cost agile” projects, we feel that keeping bugs in a separate system is the right way, although we’d be open to talking to our customers about integrating a bug tracking system directly into easyBacklog should their be sufficient demand.  Either way, we are not convinced that bugs should be seen as stories, they have wholly different demands, and are often disruptive in that they need to be dealt with quickly especially if they are holding up a deployment or worse impacting users in a production environment.  Therefore, as and when bugs arrive, the team may or may not deal with them there and then, and these are not counted towards the sprint calculations because arguably these bugs are not stories in their own right, but part of another story that was marked as complete, but is effectively no longer complete because it has a fault.

Section: Sprint communication

Henrik encourages transparency with the team by ensuring each sprint is documented and visible to the team. His comany typically set up a sprint info page in a Wiki, but it is equally valuable to simply write this information up on the sprint board and communicate to the team in the same way stories and sprint status is communicated.  easyBacklog does not currently have a Sprint information page, or a Wiki for entering this type of information.  We’d love to hear from our users whether this is something they would be interested in or not.

Section: How we do sprint backlogs

As mentioned above, Henrik talks about trying various systems for managing sprint backlogs, but in the end prefers physical boards where it is filled with story cards and post it notes, along with a manually plotted burn down chart for the sprint.  easyBacklog too believes that this is the right approach and as such we help with the printing of story cards, but leave the sprint planning and execution to be handled with physical objects and by the team.  A few of our users have mentioned that whilst this is the ideal way of working, unfortunately sometimes they have geographically separated teams and would thus like an online taskboard as well as a physical board.  Our concern with this is that unless someone updates the online board when the physical one gets updated, the online version will soon be out of date.  We’d love to hear from our users about how they like to approach this, and what they feel would work for them?

Henrik did mention that some companies are a little wary at first of using an entirely physical system for sprint management beacuse of traceability.  However, he does point out that once a sprint is completed, there is almost never a need to look back at the sprint and decompose each task and how it progressed through the system.  All that is important is how many points were completed in that story versus what was expected.

Sections: Seating and Product Owner access

Unsurprisingly, Henrik feels it is important that team members are physically seated right next to each other so that they can communicate as and when any points for discussion arrive.  Simply having a few desks of separation means that it is that much harder or less likely a person will get up and talk to someone else about any issues or thoughts they have as they are working through their tasks.

For those of us working in agencies providing services to our clients in an agile way, it is important that we consider the role of Product Owner and how they can be accessible.  A product owner is not necessarily they client, but could instead be someone within the agency who understands the objectives of the client, and has the mandate to make decisions on their behalf.  Either way, it’s really important that you consider who will be playing an active role as Product Owner throughout your project, and ensure they are accessible by the team so that any questions in regards to a story can be answered immediately.

Section: Slack time between sprints

Henrik makes the keen observation that the term sprint should be considered in that it’s meant to indicate the team puts a lot of effort in to deliver something quickly and efficiently.  However, it’s unlikely a team can maintain a sprint forever so do need time between sprints or during sprints to slow down and recover.  With easyBacklog, this slack time can be addressed in two ways:

  • Each sprint start date can be altered, so you could allow 1+ days between sprints for recovery if you want.
  • You could simply drop the average velocity to account for intentional slack time.

Section: Release planning and fixed price contracts

For us, this was the first part of the book where we felt the strategy to deal with fixed price contracts was a bit idealistic and not necessarily practical in a commercial environment.  Agencies typically have to provide quotations for work to be completed, and clients will often have a bunch of requirements that they communicate to the development agency in one form or another.  So whilst Henrik suggests that you run through a backlog and assign importance to each story, and then communicate to the client that all stories with importance > 50 will definitely be in scope, and everything below < 50 will possibly be included in descending order of importance, simply does not work in our experience with clients.  Think of it like this, if a customer goes to two car dealerships to ask for comparitive quotations, the customer would expect like for like quotations that he can compare.  When one of the dealerships comes back with a laundry list of features, but says something along the lines of: “We’ll try our best to include air conditioning and a radio with your car, but until we get into the manufacturing phase we won’t be able to guarantee you’ll have that included as we don’t know if we have enough materials at the price we’ve estimated”, you can be pretty sure the customer will go with the other dealer who is making an up front commitment.  

With easyBacklog, we help to ensure agencies can make commitments to clients about scope at the outset, but then manage change throughout the project allowing the customer to shift their focus in terms of what will be included within the budget they set out.  This is achieved because:

  • Setting up an initial estimate based a complete backlog is trivial, the tool is fast, stories can be estimated with the 50/90 rule with the team, and experience in regards to typical team velocities can be used to estimate the number of days and potential cost for the project.
  • Once the project goes into production, the estimate backlog is used as a base moving forwards.  Any additions can be made to the backlog, as can backlog items be removed or re-prioritised.  easyBacklog ensures that snapshots of the backlog are made at any point in time so that you can easily sit down with a customer a review where the backlog was when they agreed the contract with your company, and where it is now, explaining all the differences and the motivation behind them (typically driven by themselves).  Empowering your project managers with this functionality means a client can easily rectify any increases in overall budget by simply readdressing the backlog until it meets the contracted budget.
    View an example screenshot of the snapshot compare feature »

Section: Multiple scrum teams 

Henrik talks about the strategy behind multiple teams or single larger teams, and the relative advantages of each.   He says that the largest single scrum team they have had to accomodate was a team of 11 people, but he said that did not work too well as planning, demo and scrum meetings simply took to long, and with such a large team communication about what each person was doing was quite difficult.

easyBacklog does not currently suppport the notion of multiple teams, so in the sprint planning section currently there is only one sprint per date period.  We’d love to hear from our users whether they need to support multiple teams, and if so it would be great to hear how you go about managing this and what easyBacklog could do to help with their planning?  Please do tell us what you need.


Overall, we think this book is a great read for any team implementing Agile and Scrum as it talks about real world problems and how Henrik addressed them.  The book would also serve as a great starting point for new teams who can delve directly into a working methodology that is being used by successful agile teams.

We’d love to hear how you think easyBacklog can help you manage your backlogs better and if there are any areas we could improve. Get in touch and tell us what you think »

Agile for Agencies Xmas 2012 Event

Many thanks to those who attended the Agile for Agencies in November 2012, it was the most successful event so far and thank you Tullo Marshall Warren for hosting the event and providing drinks and pizzas.

Please find below a summary of the event including talk summaries, videos and links to speakers’ details.

Implementing iterative development iteratively

We are really chuffed that Rolff Kruger’s talk got so much feedback and questions, it highlights what is really needed in the agency community: talk about agile implementation strategy and pitfalls in agency land. We had to stop questions after 20 minutes so we could get to the other talks!

Watch Rolff’s talk:

The power of saying no

Simon Kirk's talk was also well received and made us think about how saying no can be more effective than saying yes. Visibility and agility in the work place can help us say no more often as it becomes evidence base, the more visibility of the work the less we will have to say no.

Watch Simon’s talk:

Agile game

Finally James Deakin made us play a great agile game to highlight the fact that self-organising team work better and short iterations allows teams to improve quicker than a long planning session followed by one shot at doing the work. We also had a lot of fun playing it if a little competitive…

This easy to organise and fun game can be very useful at demonstrating why working iteratively makes sense to anyone.

Watch the game:

We will endeavour to organise the next Agile for Agencies for the end of February 2013, in the mean time we hope you had a great Christmas and wish you a happy new year!

John & Guillaume

PS: please note the event took place during Movember…

Calculating days and cost from story points

How are days and cost calculated from story points in easyBacklog?

We’ve had a number of requests from users to explain how easyBacklog calculates the days and cost based on the story point value you enter in a backlog. In this post I’ll explain the process involved and also the formula used for those users that enable the 50/90 estimation method.

When you first create a backlog you are asked to enter a number of settings I’ll go through each one now explaining their purpose:


For those of you who have already been running projects using scrum you should have a good idea of your velocity. Enter the number of points that a team member achives on average per day. This figure is used to automatically calculate how many points a team member is likely to achive per sprint and gives you a target sprint total (depending on how many team members you’ve assigned to a sprint). 

easyBacklog also warns you if the number of points you select in a sprint goes over the expected total.

If you are new to running projects using Scrum or don’t know what your velocity for the team is then leave this blank. You can come back to this once you’ve run a couple of sprints and have an idea of what your team’s velocity is.

Day Rate

By adding an optional day rate easyBacklog can give you an indication of the cost for the backlog total, theme total and individual story. The points per day is simply multipled by the day rate to give the cost for each story.


Using the 50/90 estimation method

For more advanced users (and those running larger projects) you can turn on the 50/90 estimation method which involves adding two story point estimates to each story, a 50% and 90% estimate.

A 50% estimate means 50% of the time you will exceed the estimate and 50% of the time you’ll run under. A 90% estimate means we will be right 90% of the time.

This is espicially useful when carrying out a first pass of your backlog so you can have an indication of what the total project cost may be. You’re unlikely to have all the information on each story so can assign two story point vales to each story depending on how certain you are.

This gives you a better and more realistic buffer on a story level rather than adding a generic 20% contingency to the total project cost. You can read more about 50/90 in our previous blog post

Implementing iterative development iteratively

The basics

I recently started introducing some agile values and principles to the dev team atTMW but I didn’t particularly think that we would en up doing scrum as agencies are not always an easy place to do iterative development.

In a true agile way we simply concentrated on team dynamics and communication as opposed to processes and methodologies.

Small steps

Instead of using scrum we started iteratively introducing scrum techniques on some projects, every time we got comfortable with the techniques we introduced new ones.

We only did this on projects that were appropriate and it was always a team decision to do so. The techniques got the team dynamics going, the stories and planning helped with commitment and it helped us deliver difficult and time challenged projects and got people in the agency talking about this new way of working.

Are we ready now?

The really interesting and wonderful thing about iteratively implementation is that we got to a point where some team members expressed frustration at not being able to know real progress and be able to react to time booked against their project to ensure less interruptions, better time management and ultimately deliver on time and on budget.

We are now ready

We had a meeting and discussion about planning, estimation, iterations and scrum techniques.

We decided not to impose any methodology yet but we now require certain rules to be observed:

  • write stories if you can
  • plan and estimate
  • check your planning estimates against the original quote and mitigate any resulting discrepancies with the team
  • catch up daily and update progress (with a board, spread sheet, whatever you like)
  • work in work chunks or iterations to be defined by the team

The team is now on board and keen to learn and most of them are curious and engaged with scrum and its techniques.

We are now writing stories with acceptance criteria and BBD scenario, we print story cards with the very useful double sided print functionality and get our scrum boards hand made by the design department!

We still have a lot to learn but this is the first step towards working better together.


A sudden switch to a new methodology can work but requires huge levels of training, evangelising, organising and commitment from individuals and it can be a big gamble.

Starting with values and principles and iteratively implementing new ways of working can work wonders, everyone is involved in the implementation, can see results and team members tend to go further, they are engaged and motivated to improve the status quo.

Agile psychology

Recently I started reading the blog of Jean-Charles Meyrignac called Psychologie Agile, he doesn’t post very often but every time he does I learn something new.

Jean-Charles is a self proclaimed nerd and all that comes with it: the bullying, awkward relationship with his parents, the long hours coding video games, not taking care of himself, introverted and the inevitable depression.

With the help of therapy he changed his life round and immersed himself in agile and has utilised his personal introspection to add his own flavour and learnings to it. His ideas are sometimes provoking but always based on observation and practice, he looks at agile more as a psychological approach to working in groups and teams rather than a methodology.

His blog is in French so you have been warned, Google translate will probably make a mess of it but it might be worth trying as I highly recommend you read it.

Coffee games

In our last Agile for Agencies event Agility in Mind did a great Kanban simulation with some of the audience where the volunteers worked on a virtual coffee making production line.

We observed how naturally we follow orders, how team initiative can really solve problems quicker and in a more efficient way then orders ‘from above’ and it also did show the importance of feedback loops and better client engagement.

We also we really had a laugh, check out the video below, it’s 10 minutes long but worth watching it in one go:

Agile for Agencies second event

We ran our second agile for agencies event and it was a really good evening.

We had a good turn out of agency folk (including TMWAqueductSpecial Moves,AKQA) plus Eben Halford from Credit Suisse and Agility in Mind

I introduced the evening with Jon from Special Moves, big thank you to them for hosting the evening with all mod cons and booze. Many thanks also to  Agility in Mind for setting up the projectors, running the Kanban simulation and filming the event (videos to follow). 

John and I then did a short at about the five things we wished we’d known whilst implementing scrum in an agency. 

  • Don’t focus on tools and software: concentrate on the important things, use a board, use a tool to track stories and metrics like but don’t use it as a team communication tool. 
  • Learn the process first: as when you learn photography, learn to know all the settings and what they do before using an all automatic device and adapting it to your use.
  • Unlucky 13: stories of 13 points or higher are toxic, too much to do they also counteract the idea of knowing about progress or failure early and often. Make your stories as short as possible and of similar complexity. It evens out planning and make for better predictability of sprints. 
  • Don’t think you’ve implemented scrum and rest on your laurels: it’s a marathon not a race, constantly remind people why they are doing it and why every part of the process is important. Tackle conflict head on by using agile techniques like the ladder of inference during retrospectives. 
  • Acceptance criteria are not always enough: consider writing BDD test for complex stories with different scenari, think about how you would describe the acceptance criteria of a cash machine software. 

Eben Halford did an insightful talk on agile anti-patterns which made most of us nod in unison, his presentation is now available on slideshare

Agility in Mind did a great Kanban simulation with the audience, the volunteers worked on a virtual coffee making production line. We observed how naturally we follow orders, how team initiative can really solve problems quicker and in a more efficient way then orders ‘from above’ and it also did show the importance of feedback loops and better client engagement. We also we really had a laugh, check out the video

We ended with questions answered by a panel of speakers with good questions about , team motivation, whether we should encourage team leaders helping with work distribution, difficulty of quoting and selling more personal engagement to clients. 

Some of us went down to Special Moves' local and had a beer and chat which was a lovely ending to a great evening. 

We’ll update this post with slides and videos I soon as we get them on-line.

Agile for Agencies take 2

After the success of the first agile for agencies event ( ) we are happy to announce that the second event has now been schedule for the 17th of July 2012, you can check out the event full event details at

We have listened to your feedback from the first talk and are featuring two short talks and an interactive session which we think you will really enjoy.
After attending the first event Special Moves ( have kindly offered to host the event and we are greatfull for doing so, the event will therefore take place at their offices:
  120 Exmouth House
  3-11 Pine Street
  EC1R 0JH (

We realise that some of you were on the waiting list and hopefully this time we will have a little more space, so please register at and we’ll do our best to accommodate everyone.
The agenda for the evening is the following:

- 6:30pm Meet and greet (with beer)
- 6:45pm Introduction:  Guillaume Buat-Menard (Technical Director at TMW, easyBacklog co-founder),  John Abernethy (Technical Project Manager at Special Moves
- 7pm Talk: John Bown  (Digital Operations Director at Aqueduct – easyBacklog ( co-founder)
- 7:20pm Talk: Eben Halford (Senior Agile coach at Credit Suisse)
- 7:35pm Kanban simulation - Andrew Jones & Edward Scotcher (founder of Agility in Mind
- 8:15pm Q&A with speakers
- 8:45pm Pub!

Hope to see you there.