I have always talked about estimation in the context of unknowns and uncertainty. As developers, we speak a common language when it comes to estimation. We all rally that ‘estimation is hard and uncertain’ but I have always tried to establish that there are certain prerequisites to the software estimation process. If those steps are judiciously and accurately followed, estimation can be easy and accurate. The foremost and primary step is defining User Stories. The accuracy of software estimation depends on how well the user stories are defined, because a well defined user story can only enable the developers to assign size values to it which is essential for effort and hence time estimation.
Software estimation hence boils down to User Story and requirement analysis.
User Stories in Agile Development
I have always pointed in other posts too, that requirement analysis and hence the user stories are the most important building blocks of agile development model as it provides a refined and explained intent of software features from the user’s perspective in an all inclusive manner.
A user story defines user intention, his problem and expectation with the software feature for task completion. A clearly defined user story enables the software developer to understand what specific task the user aims to accomplish through the feature.
As a developer, I can gauge and define my user’s intention and hence the required user actions through clear definition of user stories. A user story helps us answer the questions – which user action would be triggering the system for task accomplishment and why.
The important consideration is what effect does a user story have on software estimation process? The answer is simple. Since every user action/trigger needs to be necessarily identified clearly for calculating the correct requirements for estimation accuracy, user stories and their definition occupies an important place in software estimation process.
Let me now focus on user story format, benefit and how estimation is done through user story.
A user story format covers the role, feature, and reasoning behind it. The user story is written by the business for both the development team and the business about the usage, feature, and intent of use. All of the user stories explained above have a role, a specific requirement/feature capability, and intent behind the user’s task accomplishment. The software developer’s role is to define every user story in these three descriptions for accurate estimation.
Various functional requirement types can be described through user stories – technical as well as non-technical. While uploading an image for photo sharing is a non-technical requirement and a usage requirement, enabling digital wallet online, through a standard browser is a technical requirement. User stories foster clarity and mitigate hidden risks. A well defined user story has the potential to reduce the level of uncertainty in the estimation process, reduce potential risks of unknowns and establishes accuracy in effort estimation. It promotes greater clarity between the role player, the what (user and feature definition) and how (technicalities, estimation and coding) of requirements.
Once your user stories have been well defined and story points have been set, effort estimation can be done by assigning values and magnitude to the story points and calculate the time required to implement it.
Assigning Magnitude to User Stories
When user stories are well defined it becomes easier to assign an order of magnitude to it for estimation. This could be a range or scale starting from 1-10. Planning Poker technique of Agile methodology uses cards from 1-13. Planning Poker is a collaborative knowledge sharing session where the team can discuss what is present and what is not present in each item during an estimation session. The process aims at building consensus within the team which is very important. Estimation during planning poker generates knowledge through collaborative effort.
An estimate of the story point can be either be numerical (1, 2, 3) or superlative degree wise (high, medium, and low).
I would always recommend that estimation should be done in relative terms instead of exact number. I normally assign a point to each user story and try to come up with a relative indication of the time that would be required by programmers to implement the requirement.
A unique identifier can be included for each user story to establish linkage between user story and other artefacts. So if I identify and give a number ‘3’ to a certain implementation type/unique identifier ‘A’, all other story points should be estimated in relative comparison to this particular identifier ‘A’ . This process is precise and relative estimation can help describe and apply the degree of complexity to all identified story points with greater ease and clarity. Instead of delving into each task for estimation, an identical implementation type needs to be established and use it as a scale to define the complexity and hence the time estimates.
Prioritization of User Stories in the Software Estimation Process
Another point which we should not forget as developers is prioritization. Requirements and identified bugs should be prioritized by project representatives/project owners and assigned a proper place in the user story card stack. The prioritized requirements can be managed in the stack as per deemed necessary. Every user story is thus assigned a priority.
Regardless of the prioritization strategy used, the purpose should be aimed at simplicity and doing the estimates in quickest time.
When I speak of producing estimates, I speak of identifying a process of software estimation where the estimates of effort, time and budget can be developed in shortest turnaround time. This would enable us as developers to create our unique competitive advantage on one hand and save us from elaborate estimation procedures (prone to over and underestimation) on the other hand.
The surest and shortest answer to this issue is to simplify the estimation procedures, once user stories have been well defined through auto estimation software. Quick FPA produces the quickest estimates irrespective of the size or complexity of project in hand. Any analyst can perform the estimation with greatest ease and flexibility. The only primary task is to clearly identify and define all the user stories and set the correct requirements to prevent any scope creep.
I would strongly recommend companies to focus on two important steps for success of their software project – correct user story definition and hence doing correct requirement analysis AND using a software estimation tool like Quick FPA to create the quickest estimates for their project. For greater detail you can register on this website and get an invite for more clarity.