A summary of the 02/08/2016 Digital Project Managers meetup on agile planning.
Gather the whole team for this exercise. e.g. UX design, developers, testers, product managers.
Discuss each job, and collaboratively rank the jobs in order of complexity.
Think about all the work that will be required to get this job ready to go live.
For each job, some elements might take more time. E.g. UX might take a long time on one job, but the development might be quick. So you need the different perspectives involved in the discussion.
Groups similarly-complex jobs together.
Apply T shirt sizes to these groups: S, M, L, XL, XXL.
If you have anything XXL, break it down into two or more different jobs.
Assign ‘story points’ to each job, based on its size:
(If you’re running an internal team, there’s no need to think in terms of hours.)
Estimating velocity (how much work you can get done in a given time period)
If you’re an established team, you’ll know from experience how much work you can complete in a given period.
If you’re a new team, you’ll need to collaboratively estimate how much work you think you could carry out in a given development sprint (e.g. 2 weeks).
Work through each of the jobs, and combine them into groups showing how much you think you could carry out in a sprint. Then total the number of story points of the jobs in that group.
Once you’ve done this 10 or more times, work out the average number of story points per sprint. (Round down to the nearest whole number if required.)
This is your estimated velocity – the number of story points you think you can complete in a given sprint.
Prioritising jobs to build a plan of work
Prioritise all jobs using force rank: the highest priority job goes at the top, the lowest at the bottom. Nothing has equal priority.
You can also factor in sequence dependencies (and so promote some jobs that are required to allow you to complete other, higher priority jobs) and highlight milestones (points where you’ll have something specific to show off).
Once you have this ordered list of jobs, lay them out into separate sprints, totaling the number of story points you think the team can achieve during that sprint.
N.B. to adjust for team size, the time of year (e.g. holiday season), and to leave a % for emergent scope: between 20 and 40%, depending on how confident you are that the stories are comprehensive.
Managing ongoing development
Scope is variable. The plan isn’t fixed – it’s an overall route map.
Estimates are fixed. Once an estimate has been made, don’t change it. Retroactively changing estimates wastes time, and disrupts your statistics.
If you aren’t able to get through as much work as you expected, you need to have this recorded in the sprint burn-down. Reflect on this in the sprint retrospective. Re-project your velocity as required.
New stories are sized with reference to existing stories. This makes it quicker to estimate new jobs, as you can compare them to other similar jobs already completed. So estimation becomes easier and quicker over time.
Update your burn-up chart each sprint.Track the speed to the target (velocity) and the distance from the target (scope).
Once your team is established, use their measured velocity and use this to re-project timings. This is more useful than the estimated capacity that you use when planning with a new team.