I’m Benjamin Jalon, a software engineer at Nuxeo and in charge of our agile development practices. One of my missions is to keep Nuxeo’s engineering teams nimble and efficient by continually pushing them to improve our development processes and methodologies. This blog will highlight how we strive to meet these challenges and offer guidance to our clients and integrators so they can do the same. As you might know, at Nuxeo like at many quality software houses, we use techniques from Japan and a strange term from rugby.
Work Load Estimate, The Nuxeo Way
How many times in my working life have I heard a developer explaining to his wife that he will finish in ten minutes? How many times have I told my own wife that she can start to cook because I will be at home soon? Enough times to know that developers’ wives eat alone and burn food. So, exactly how can one have a realistic estimation of time required on every engineering task — specifically, an estimation that will provide a sound basis for planning and an accurate projection of implementation time and costs necessary for our customers to integrate a new feature?
The answer lies not in the elements of a single task but in the dependencies that exist within each. This means that a developer must first calculate the complexity of a task. Although he may not know how many hours it will take to complete the task, he knows the complexity naturally. To illustrate, I will walk you through how we make a time estimation here at Nuxeo.
For estimation sessions, we apply the scrum method (see here) during which all developers who will be part of the project will try to estimate, not the time, but the complexity.
We wanted to drill into our engineers’ minds the question: “What is the complexity?” and let developers forget the time factor. In the past, we used point evaluation, but eventually we preferred to switch to a vocabulary of complexity as I quickly noticed that it was easy for a developer to equate points with time — too often I would hear: “Ok 1 point is 1 hour!” and we didn’t want this.
Our complexity evaluation vocabulary is now standardized throughout the company:
- Hard Core
- God Mode
- Linux reimplementation
Hopefully we will never have to execute Linux reimplementation.
Teams at Nuxeo are punctuated by small [time based] iterations. Each team has their own rhythm (for Atlantis team and support team, this is 1 week and for Starship team 2 weeks).
During these iterations, the Product Owner (see here) asks to the team to execute a list of tasks ordered. Each day, each developer puts on the post-it note that represents the task how many hours he worked on that task. At the end of the iteration, we have the time spent on each task finished.
But during the week a Nuxeo developer has meetings, support questions to answer, etc. All these tasks that are related to his work must be taken in consideration. To accurately represent these aspects, we determine a fair average and incorporate the time spent in these endeavors into each finished task during the iteration.
We do this by utilizing a google spreadsheet such as this:
Each line represents a task. We have the real time spent column where we record the time that the developer has logged. If you calculate the sum of the time spent we have 70 hours.
And to log the team activity, we note that Laurent and Sun were present the first day of the iteration, 3 developers the second day, etc.:
In total, 11 days were available. In France we work 7 hours per day (maybe not for a long time :) so for this week, so 77 hours were available. That means that 7 hours have been used on other tasks. We could say that the focus factor of the team was 91 % (even if in scrum the focus factor is not the same). This value is exceptional, but this team was particularly focused in this iteration.
So we spread this additional time spent fairly, as shown here in the last column (time+HS time):
As you can see, we considered the second task finished in 5 hours, but in actuality, the cost (in time) was 5,5 hours, etc.
We assign each complexity a final cost based on an average of time + HS that is necessary to complete each task. This is represented here where we can track the statistics of each iteration:
To keep our statistics as accurate as possible we keep a history of results for the last 23 iterations, which helps us deal with estimation accidents (such as a “trivial” task which took 24 hours instead of 3). This is done by simply writing in our spreadsheet iteration after iteration, rotating on this 24 line table.
And for those who like pictures the process can be visualized in this way:
In the end we can easily see how a complexity is assigned a cost:
A “trivial” task costs 3 hours, an “easy” costs 9 hours, etc. With this tool, we speed up our estimation session based only on complexity of tasks to do. I then translate the complexity into time.
And now developers’ wives can eat warm food with their husbands.
Next up, we’ll see how we manage our planning.
Note: In the team activity spreadsheet, to count the x’s, I use this spreadsheet function: =COUNTA(L2:AC6). This gives a count of non-empty cells between L2 and AC6.