Planning session at Esendex
At Esendex we have great developers, always brimming with enthusiasm and good ideas – and they write some brilliant code, but to make sure that brilliant code benefits our customers, we have to be very well organised.
The process of developing software at Esendex is organised into two week cycles called ‘iterations’, we find two weeks is the best balance between keeping us focused and allowing room to adapt to the unexpected.
At the beginning of each iteration the development team will sit down together and plan the work we want to complete – and by ‘complete’ we really mean complete – out there in the world, benefiting our users.
Ahead of planning, work is written out on cue cards and organised into Stories, Bugs and Technical Tasks. All the requirements/acceptance criteria for each story have been gathered; this can also include UI mock ups and copy. – If these aren’t gathered upfront then we aren’t able to come up with an ‘accurate’ estimate.
So before planning we already have a basic idea of what work we have coming up and what the order of priority is.
Reducing uncertainty
In planning we go through each card in order of priority, review the work we have to do and make sure the team has a clear common understanding of what needs to happen to implement the functionality described on the card. This can take the form of discussion, a quick look through some source code or a review of common standards and solutions to the problem. If the team cannot achieve this reasonably quickly, a task card can be created to investigate and gain a better understanding of what needs doing so it can be properly planned.
Estimating size
We’ve even created our own jazzy planning cards
Once the team is satisfied the task is properly understood its size must be estimated. There are a number of ways to do this but the approach we prefer is ‘Planning Poker’. In Planning Poker each member of the team holds a set of Planning Poker cards, on each card is a number and when presented with a task, each team member privately selects a card which they feel represents the effort required to complete the task. Then at the same time, all team members reveal their estimate and based on everyone’s estimates a discussion begins and the team agrees on a team estimated number of points worth of effort for the task.
Initially, the points value is arbitrary, but very quickly, as the relative points to complete different stories are compared, a currency of effort emerges:
“If the fix for the login page is a 3, and adding updating the sent messages page is a 5, the new API endpoint story must be an 8…”
Each team will establish a standard for what the points value of different tasks are, and will be able to identify when a task is too large and needs to be split into several smaller tasks.
Turning effort into time
By recording the number of points completed, within a few iterations the team will gain an understanding of how many points they can usually get through in one iteration, this is known as the team’s Velocity. The team’s velocity is used to estimate what tasks can be feasibly completed in the next iteration and what cannot.
Further reading
Of course there’s a more to it than just the planning – the organising, the prioritising, the doing, testing, deploying and releasing … but get the planning sorted and it’s a major roadblock out of the way of the developers. If you want more information, we’re big fans of Agile Estimating and Planning by Mike Cohn , but most importantly give it a try and don’t be afraid to tweak and adjust it to make it work for you and your team.
