When you have already found the team for your software or hardware product development and all the requirements are ready, you’re probably on the stage of planning the development process itself. We described in our previous article some general principles of the workflow (what a sprint and backlog mean, who stakeholders and product owner are). Now, we are facing the question: How do you estimate the time and efforts that developers need to dedicate to a certain feature development and your project in general?
The aim of estimation is to find a corresponding value that will tell you how much money, effort, resources and time it will take to develop a product. We use Story Points to estimate development projects.
What do 'Story Points' stay for?
A Story Point is a theoretical measure that expresses the difficulty level of any piece of work. The difficulty level is usually influenced by several factors such as the volume of work to do, the complexity of the work; any risk or uncertainty in doing the work. For example, removing some UI element, like a button, is an easy task, while developing tablet support for a smartphone app requires much more efforts.
Of course, the more work you send us to do, the higher estimate of effort will be. The estimation will be affected if you give us unclear requirements, which cause uncertainty. Or, if a feature involves modifying a piece of old code, the estimated value will also rise up, because of the risk possibility.
You might agree that estimating some item as 97 and another as 98 (out of maximum 100 points) appears to be quite vague since a 1% increase in effort is confusing to tell the difference. We use the following common values 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100 to estimate with story points.
How does the estimation with Story Points go?
To assign Story Points to each item in backlog we hold a meeting, where all specialists that will work on your project get together. So your Product Owner picks an item from the Product Backlog (a wish list of all the things that need to be done), the development team members ask multiple questions and discuss the item so that they understand the details of implementation. The discussion helps everyone see a different perspective of the product.
Next step is an estimation itself. We do it individually by choosing a card with a particular value that reflects the level of effort for the work item. When all the members are ready with their Story Point — they reveal their cards at the same time to see whether the values match. If they do — the team picks another item from the backlog and goes through the same procedure. If not — the team takes some more time to figure out the common estimate.
An important concept of assigning Story Points to items from the backlog is that the team members are not actually ‘voting’ and in the result, they will not elect an estimate that just simply gets the most votes. In preference, the team will take into consideration the opinions of each team member, therefore the reference of the specialist who is most familiar with the exact part of work will make an impact on the final decision.
Note: since story points are relative by their very nature they are largely related to the project context. Ie. mobile projects will have 'smaller' story points comparing to enterprise-level applications. The following explanation and examples are given for small to mid-size mobile/web projects.
As an example, here’s an estimation of a sample application that would allow the user to create an account and seek job possibilities with basic messaging functionality.
On the whole, estimating your project with Story Points helps better meet your time expectations for future work. When all backlog tasks are estimated in terms of Story Points, we are able to determine how many sprints we will need to run to complete the project.
Contact us to discuss your project idea.