Mapado is one year old ! One year with a 5 people team (6 now since a month), and one year with Scrum. Nobody had really used scrum or agile software development before that.

Here is our feedback about this year.

Meet the team

Here is our team:

Two bosses: Jerry working every day with us in Lyon, and Nicolas working in Paris who spend one day per week with us.

One graphic designer (Christelle), and four developers (three during the all year, one who was hired a month ago) (Balto, Dimitri, Epi and me).

Here is more or less how we choose our scrum roles:

Jerry works in Lyon, he  became the product owner (he knows what the product has to become on a sprint to sprint basis, between the “big picture” and the the code behind).

As I read the (great) book Scrum and XP from the Trenches, I was the scrum expert (compared to my colleges), and became the Scrum master. (OK, maybe I also am the annoying guy who always wants to do things by the books 😉 )

The first sprint

We choose a sprint length of 10 working days:

  1. Week 1 on Monday morning: Planning meeting
  2. Week 2 on Friday morning: Demo and retrospective
  3. Week 2 on Friday afternoon: non-scrum things

We chose 10 days because that it occurred to us that the common sprint duration was between one and three weeks. Two weeks seems to be a good fit.

We chose to do the daily meeting at 5 pm, just before the firsts of us leaves (OK, still me 😉 ).

The books tells you to use an arbitrary number of story points, but how much the first time ? We used a reverse technique: we estimated some tasks, and when we thought that we could only do those tasks in the sprint, we stopped and had our number.

We had more or less 40 story points.

A couple of sprints later

The “more or less” was a little more, a little less each time. We were stunned by the fact that some times, we blew up the burn down chart, some times, we treated only 10 points during the sprint.

The graphic designer really played the game, and it force us (developers) to keep discussions as understandable as we could.

We also have a little challenge: we hope that one time, all the team will be united in the planning poker for every story. In this case, we would win a badge like this one.

First thoughts about SCRUM

After a couple of sprints, we thought back at one think we did wrong: our burn down chart had 10 days. That was wrong. As I said, the whole sprint is 10 days, but the work time is 9 days (even 8 ½ days) !

We tried to add a “need review” and an “unplanned” column on our board, but we had no use for them:

  • We use github “pull requests” system for code review, and we only move the stories from “in progress” to “done” when the pull request is merged
  • We do not really keep trace of unplanned items for the moment: we still are young project, with little bugs to fix. There are some unplanned tasks, but nothing too big for the moment (or maybe we should start keeping trace of them…)

The product owner has a lot of ideas. Every day. But he understands that it is annoying for us to constantly switch from one task to another. The two week sprint approach is a good idea for him: first of all, if the idea is still alive two weeks after the first thought, it is worth developing it. If not, we did not waste time experimenting it.

The big thing we have done wrong

After a while, we realized we were really bad with estimating good story points.

I think I was not a good Scrum Master on this one: I agreed with the team that the number of story points could be floating. As a matter of fact, we still were estimating our stories globally, even if we kept points on each story.

What we tried

We tried to do a more flexible approach of agile development: a mix between Kanban and Scrum:

  • We erased our burn down chart, we do not vote on each task: we explained and sorted them, and just decided where the limit was.
  • We kept the ten days sprint, the daily meeting and the demo.


It worked for one sprint.

The second sprint was just awful:

  • we had to look on a website to see our tasks (we do not print them)
  • we did not see where we were, nor what we had done at the end of the sprint, as there was no burn down chart
  • we did not manage to “push” code, and we did not finish every task.

We hence switched back to Scrum.

A team of specialists

We made something awful: we calculated our “conversion rate” between story points and working days. I know, you can’t do that, it’s not agile. Whatever.

We are a specialized team:

Christelle is a graphic designer, who does not write code. Balto is a Python developer, who is fully occupied by Python tasks and does only understand unicode graphical interface. Dimitry and me, PHP developers, who sometime perform Python tasks.

We compared how do we vote for stories:

Christelle converted 13 story points to 5 small working days. For Balto 13 story points is a big week, like 6 days. For Dimitry and I, 8 story points were a big week, maybe 6 or 7 days.


So since sprint #20, we vote in “Story point days”. Story point days are like Virtual dollars where 1 virtual dollar = 1 dollar. For us 1 Story Point Day = 1 working day (but it is not the same AT ALL, as it would go against the agile manifesto this way ! 😉 )

Sprint #20 was better, but we still rated very small tasks with 2 story points. We are now in Sprint #21. It is even better. We will see in one week the real result.


Scrum seems to be a good approach for us. It is now perfect, but I do not see a better method for now.

Jerry let us work two weeks on the tasks we decided together. He gets a great demo each two weeks. During this time, he can think of the next changes or improvements he wants to make on the product.

As a team, we can work on the tasks we want, and we have the choice of how to perform them. Each one of us has its preferred tasks of course, but we often discuss together to make the best technical choices.

Our great team makes the Scrum master position quite simple. Everybody sees the benefits of Agile methods. The only difficult rule is to keep the daily meeting a “report” meeting, not a “discuss” one.