Agile Stance Series Part 6 - Estimation (2 of 2)

This is part 6 of the series of post around Agile.

Estimation (2 of 2)

Planning poker is an effective estimation aid that promotes a collaborative estimation consensus between the Sprint Team. The technique involves each member of the Sprint Team making 'silent bid' (estimate) using a playing card by placing it face down. By placing the card face down, each estimate is not influenced by any others. If all estimates are the same, a consensus has been reached. If there are differing estimates, this bring conversation on what people see as being involved in the task taking the team into a deep level of understanding and ironing out assumptions that have been made.

User Stories that that cannot be completed in a single Sprint, must be broken down into smaller manageable chunks. When the second User Story is selected for estimation, it is compared to the first. If it is twice as complex, it will be allocated twice as many Story Points. If it's half the complexity, it will be given half the amount of Story Points. If it is of a similar complexity, it will be given the same amount of Story Points. The key to this technique is maintaining a consistency and estimating each User Story consistently with the previous User Stories. Maintaining consistency will allow the measurement of velocity over several Sprints. Without this consistency, the value of velocity and forecasting are lost.

The estimation will be an estimate to complete the User Story in its entirety, including analysis, development, unit testing, integration testing and acceptance. This emphasizes the concept of multi-functional teams, where each of the Sprint Team member will be required to do more than just a single task, be that task analysis, development, testing or integration. The Sprint Team is a dynamic group of individuals that are able to support each other and handle a range of tasks and responsibilities.

Agile Stance Series Part 5 - Estimation (1 of 2)

This is part 5 of the series of post around Agile.

Estimation

Once User Story concepts have been listed, the sprint team will review the User Stories with the Product Owner present and ensure that they have a good understanding of what is involved with each User Story.

During this process of going through each User Story, the Sprint Team will make a points (Story Points) based estimate of the complexity for the User Story.

Story Points based estimation is a way to purify an estimate free of extras such as padding like contingency and other additional time added to tasks. A task is what it is and is rated by its complexity rather than the time it will take to complete.

The time to complete a set of User Stories will be reported on at the end of the Sprint giving the velocity of working for the Sprint Team. This also allows for team members of different skills levels to view User Stories with the same measurement. A User Story of complexity 5 story points to a senior team member will also be a complexity of 5 story points to a junior team member. This begs the question, what is the value of a Story Point!

The value of Story Points are relative to other User Stories completed within the same project, by the same Sprint Team. Estimation is begun with a single User Story. It is rated by its complexity by a measurement between specific parameters. This could be numbers for example 1 to 6, t-shirt sizes x-small to x-large or anything that the Sprint Team has a common understanding of and inspires them. The only rules are that largest complexity rating must be achievable within a single Sprint duration and must be collaboratively agreed to by the Sprint Team.