Estimating and Planning and monitoring day to day development is a lot
of what's involved in the job of a team leader. This is the approach I
take to this, I don't claim to have created any of this, rather it's
just the collection of agile methods and tools that I find useful. This
is what I do for sprint planning every 2 to 3 weeks. When doing
ball-park planning for a longer period I follow the same basic process
but at a less granular level with corresponding drop in accuracy.
Before Planning
There are a couple of questions that really need to be answered
pre-planning. This is the side of planning that's often not visible to
the juniors in the team. It's the bit that gets forgotten about and
contributes to that wonderful "I don't know what my manager does, but
when they're away it all goes bad" feeling in so many well run
development teams.
The two questions you need to answer are
- How much time do you have?
- What are you trying to do?
How Much Time Do You Have?
The whole point of planning in an agile project is to commit to a given
set of tasks to be delivered at the end of a sprint. To do this you need
to know how much time your team actually has available. This can look
like quite a daunting question, there is any number of meetings,
sicknesses and other distractions to take your developers away from
your sprint.
The good news is that it actually doesn't matter that much, all of these
things can be rounded up into "good enough" percentages or buckets so
that they balance out over time. If it all goes horribly wrong, then you
can always stop and re-plan. There is a cost to this but there are times
when it is necessary.
Like all managers, my worlds seems to revolve around a series of
spreadsheets, so of course I use a spreadsheet to work out how much time
I have available. Nice and low-tech. Basically I crate a table like the
one below. The days of the sprint (or period being planned) down the
left and how many hours each developer will be contributing to the
sprint.
| Bob | Mary | Alice |
| Mon 17 Oct | 6 | 6 | 2 |
| Tues 18 Oct | 6 | 6 | 2 |
| Wed 19 Oct | 0 | 6 | 2 |
| Thurs 20 Oct | 0 | 6 | 2 |
| ..... |
| Total | 30 | 48 | 14 |
| Grand Total | 92 |
I plan based on 6 hour days which gives enough time for the general
meetings, interruptions, email and the like which is just part of a
normal day. When I have someone new in the team that's still coming up
to speed I scale back the amount of hours they logically contribute to
take account of the lesser productivity and impact on the other members
of the team. E.g. in the table above Alice could be new and while
working exclusively on my project is only logically contributing 2
hours.
It's tempting to extend this to try and account for the difference in
productivity between Juniors and Seniors. But I find that this just
complicates the process and warps the results. The standing differences
are easy enough for the team to take into account while estimating as
they know each others abilities. The reason we decrease hours for a new
member is more about the fact that they're an unknown quantity to the
team and at least a part of their contribution will be cancelled out by
training and support time from the existing team members.
So now that we've done that we've got 92 hours right? No. In addition to
the usual non-project stuff that's covered by assuming only 6 hours a
day, there's generally an amount of project stuff that needs to be
accounted for but is not so easily quantifiable as tasks. This is things
like support of existing versions that are already deployed, supporting
testers, technical writers and other members of the wider team and even
fixing show-stopper bugs that block testing of your last sprint (there's
never any of those right?).
I find it's good to actually track these things as it creates visibility
on what the team is doing and provides a good bell-weather to see if
these things are getting out of hand and derailing your planned work. I
generally pick a reasonable "hours per day" number for the entire team
and then multiply by the total number of days regardless of the number
of developers. E.g. I'll generally pick something like 2 hours per day
for "general support", so in a 7 day sprint I'll have a 14 hour bucket
task for support that the developers can draw on.
If these bucket tasks start to blow out above your allocated time then
it's time to re-plan because something unexpected has happened.
Generally these estimates can be refined sprint to sprint by looking at
how much time the developers actually spent on these buckets.
One thing to remember about buckets is that unlike time-boxes they
decrease as the sprint goes on. I don't care if you haven't done any
support all sprint, you can't do 14 hours of it on the last day.
What are You Trying to Do?
The other key question you need to answer is what are you trying to do.
What are the candidate tasks. This may seem obvious but I find the
biggest single indicator of how good planning will be is whether the
feature is broken down into good sized tasks before we actually start
planning.
I find it makes planning work a lot better if the initial breakdown and
approach have been thought through before hand by at least one
person. The key is that this pre-planning breakdown is only a straw-man
and a starting point. It will change during the planning but it helps to
have a starting point to frame the discussion.
There are three things that I consider when breaking down tasks for
planning. These are the same things that I consider when breaking down
tasks before planning and during the planning session.
- Small
- Testable
- Independent
I try to break features into small enough tasks that they can be
completed in 2 developer days. That's 12 hours based on my 6 hour days.
This is not a big period of time. The reasoning for this small size is
that if you get much bigger then the details tend to be forgotten during
estimation and the estimates become overly optimistic. Developers will
need to constantly re-estimate the time remaining on each task as they
work on it. Having such small tasks makes this easier as the developers
are only needing to think a couple of days out at most during this
re-estimation.
There are cases where you really can't break things down to this level.
Generally this means that you really don't know enough about what you're
doing to get an accurate estimate in the first place. In these
circumstances you generally need to just allocate a time-box to
investigate the issue. The core deliverable in this case is not actually
the change it's self, but the broken down tasks to be estimated in the
next sprint.
Equally important is that each task results in something that is
complete and testable. The main reason for this is to avoid thinking
something is done then having to come back and re-work it. If the task
results in something that can actually be tested then you can be far
more confident that it's done and dusted and you won't need to come
back. This also means that you can't generally split off the non-coding
tasks. Each task needs to include the code change, unit testing it,
updating the documentation, development guides, handover of the task to
testing etc. This means that 12 hours is starting to look really short
indeed.
There are some secondary reasons for this which are worth keeping in
mind. Because each task is testable, it's also visible to the project
sponsors. This avoids the situation where it appears there is no
progress because infrastructure is being worked on first. This allows
for a tight feedback loop that can nip problems in the bud. The other
benefit is that because everything is testable, system testing can take
place on nightly builds or the like as soon as the task is complete.
This can result in bugs being found and reported while the code is fresh
in the developers mind, reducing the cost of fixing them.
The final criteria I aim for is to keep tasks as independent of one
another as possible. The goal is to allow as many tasks to be done in
parallel as possible. If this is forgotten about you can get chains of
tasks that while effort wise will fit in the available resource, will
not actually fit in the time allocated to the sprint because they can
only be done one at a time. There will always be some dependency but
they key is to avoid this where possible, but if it can't be avoided, at
least identify it to ensure the first tasks in the chain are done early
in the sprint.
For all three of these concerns I generally find that taking a vertical
slice through the feature is a good starting point and then enhance
around the sides. This does mean you usually have a first task that has
to be done, followed by several enhancements that extend the edges.
These enhancements can generally be done in any order and even done in
parallel you have enough developers.
For example, take a slice through the entire system, add a screen,
service and data access layer that don't really do anything but get the
communication happening. Then add one field or function into all three
levels. Rinse and repeat. It's always tempting to break the feature down
by levels, e.g. do the data access first, then the service, then the
screen. This is problematic though, because you don't know that you
won't have to revisit the data layer when you do the screen.
Tools
All the above is really just general approaches it doesn't require any
tools beyond a spreadsheet. That said the right tools can make this
easier. Particularly if you can do the breakdown and planning in the
tool you're using to manage your backlog it avoids a lot of double
handling.
Personally I use Jira with
the greenhopper
plugin. These are not free tools but they're not overly expensive
either. Jira is our source of truth about what we're working on and what
is coming up. All tasks, features and bugs are raised in Jira.
Greenhopper gives some nice tools for working with the above process. A
virtual kan-ban board (those post-its that people get so focused on when
they hear about agile). There is also good support for doing a the
burn-down and other charts that are useful for monitoring the work in
progress.
On the planning front, Greenhopper provides a really quite stramlined UI
for triaging, ordering and breaking doww tasks as they come in which
lightens the load of doing this stuff.
There are comments.