Estimation of User Stories (Features) in PSI planning – Scrum (Agile) Methodology – Tips & Techniques

In Scrum Methodology, the estimation of identified user stories is an essential and important aspect. In-fact the software estimation is a challenging task and it depends on the nature of the software,  technologies being used to implement the user stories or it may depend on the kind of past product knowledge or the team
experience level on the product lines and domain knowledge. It so happens that there are always "forgotten tasks or scenarios" which were never thought of during the estimation process.  In accurate estimations lead to bad burn down charts and graphs which usually management keeps an eye and reviews on regular basis. So when there is an accurate estimation (as much as possible), the sprint work goes smooth.  In this post, I would like write what are the best practices, techniques that help us come up with accurate estimations.

• Never ever take single person's or individual's estimation granted. The estimation has to be a collective decision from all the participating scrum members.

• Compare the story in hand with other past done stories before giving an estimate for it. Every team would have done similar tasks in the past and there can be estimation data. The organizations that maintain good matrix have an advantage of predicting the estimation basing the past matrix.

• Pokar planning has been proven effective method in software estimation. In this method, each scrum team member is bunch of card with relative size or the estimate written on them. The user story is read out and each team member is to think and project a pokar card that has the most accurate size/effort. Everybody's pokar says different effort, and then team members discuss themselves why each team member is thinking that is the most accurate and brain storm the user story again and come to a common estimation that is agreed upon by all members.

• For the user stories which are unclear or there is no sufficient clarity, they are in-fact the spikes and team should not even estimate for implementing it but an investigation story to understand more on the particular user story. Because, sometimes team requires time to understand the user story and which is very essential for estimation.

• Consider the 'side effects' of implementing a user story in an existing software, such as impacted areas and testing scenarios. This is mostly 'forgotten' aspect and hence estimation has to include testing effort of the user story in all the affected areas of the software as the need be.

Estimation requires the scrum team to enough experienced. There should not be any estimation issues in an 'Self Organizing' scrum teams. The becomes self organizing after team members work together for long time and there is a common frequency among members in undertaking any work. The estimate created by a new member who recently joined the team may not be accurate and its obvious and this is the main reason why Pokar planning is highly recommended.