Estimation means, to guess, how much time someone – a team, a single person, etc. – will need in order to deliver work packages. It is very common, that those estimations are too low, even though, if there is no time pressure. People tend to believe, that work packages can be delivered faster, than they in reality can be.
Estimations are made, in order to create sort of release plans and charts, which can be tracked afterwards, if the timing is still ok. A lot of discussions are going on, whether it is smart, to do such estimations or if it is worthless at all. For some examples, it is kind of important, especially when it comes to allocation of resources (time, money, people) as well as in terms of coordination of different teams, who are dependent on each other’s work. This means, estimations make sense if decisions have to be taken. If those decisions are not very significant, estimations don’t need to be done, as on that case, it can be seen as a waste of time.
To sum the meaning of estimation in agile projects up, it helps to make decisions and understand when changes in the project plan are needed. In other words, it helps to decide, how changes (e.g.: new features) can fit into the project plan. In an agile project, the project plan is sort of a baseline, which is adapted permanently based on needs and re-estimation.
Selected Estimation Techniques:
· Planning Poker
Planning Poker is a method in agile project estimation in which all project members participate. The product owner is telling the user story or describing features to the project members. Each member has a set of cards with numbers on it and votes for an estimated time, until that work package can be delivered. After the first vote, the members discuss their answers and vote again. A decision is taken by consent. Subsequent meetings throughout the project are needed. Planning poker is a great tool for agile estimation, as it brings together different opinions of all experts involved. Therefore, the estimation is much more precise and including all relevant information.
· The Bucket System
The Bucket System deals with relative sizing. Teams compare different user stories and estimate them against each other. The team can easily tell, that the one story is much more complex than another or is just half as complex. Each story receives a number then and is collected in a bucket with different numbers: 1, 2, 4, 8 or 16. The biggest bucket, 16, contains all the stories that are too big or too hard to understand and therefore can hardly be estimated.
· T-Shirt Sizes
The T-Shirt Sizes technique is a very fast way of estimating. Different items / features / work packages are categorized into t-shirt sizes, eg: XS, S, M, L, XL. After the estimation is done, the sizes can also be given a numeric value, but this is optional. The decision about what size to take is made via open discussion and votes.
· Ordering Protocol
Ordering Protocol means to place the work packages randomly on scale from low to high. Step by step, every person involved has the opportunity to change the position of one work package one lower or one higher, can just talk about it or pass. IF every team member passes, the estimation is done. Various similar methods exist
Those were just a few example methods for agile estimation. In can be summed up, that estimation meetings are a quick process to decide how much workload specific packaged need. Based on the fast, that project members are involved and discuss together, the estimated time is quite precise. Of course, it is needed, to re-estimate timings within the project timeline.
Sources:
Comments