Simple techniques to support the project planning, sprint planning and refinement relative to the capacity of the team
Introduction
Estimation of size should happen around the same time the User Stories are created. The quality and accuracy of the estimates will depend largely on how early you are engaging potential team members who understand what it takes to build the product. Estimation is crucial in making strategic decisions about priorities and project releases.
When closer to the build cycle, the estimation can be ratified by the creation of a more detailed task list for each User Story, and replaced by a more accurate sizing metric. Assessing how different the two figures are is great learning to support planning both within this project, and in related projects too.
Different Sizing Options
Detailed below are some ideas as to how you would structure the sizing framework for both the estimating and sizing throughout the project.
1. Team Sprint Capacity: Team capacity is pretty straight forward – how much work can the team complete within a given period. 1 day is a long time, 1 hour is a pretty short time. A very common way of simplifying the way you measure this is to assign a points system. E.g. Half a day of work is 1 point. Therefore, each person working full time on the project for a week can cope with 10 points of work. Then you simply factor it up against the amount of people, and the amount of time they have available over the duration of the Sprint to give you total sprint capacity.
2. User Story Points: Once the User Story has had it’s task list created, the Build team will be able to estimate how long it will take to complete – the estimates will improve over the life-time of the project as the team gel and actually begin producing. This should be measured using the same system as per the Team Sprint Capacity – if it’s 3 days work for 2 people it is measured as 12 points.
3. T-Shirt Sizing: An alternative to a Points approach, you work to t-shirt sizes – Xtra-Small, Small, Medium, Large, Xtra-Large, Xtra-Xtra-Large etc.
4. Landmark Sizing: Another alternative is to use landmarks or buildings – The Gherkin vs the Shard as an example.
Whichever approach you take, what matters is that everyone understands the system and can easily work with it. Also, take a look at WIP limits – just because you have that capacity doesn’t mean you should fill it!