Better Approach To Project Estimates
Srijan’s Discovery Workshops, as a part of the software prototyping services, help our clients ideate, wireframe, and prototype their product ideas and websites before getting on with coding and development. This helps get an accurate estimate of cost of development of features.
Collective Wisdom of Teams for Estimates
Armed with documentation from workshops, mockups and wireframe,s and sometimes even prototypes, teams sit together to build a product backlog. Such backlogs consist of user stories.
The process of creation of user stories leads our SCRUM teams to discuss each feature in detail. The process ensures that technical things that might have been missed out during workshops are captured during this exercise.
The team takes the ‘simplest story’ and estimates its complexity as 1 (lowest complexity). They play Poker Cards to estimate complexity of stories and rank each one of them. If there is a variance in the complexity estimation of a story among the team members, they discuss it amongst themselves on how they would implement the same, until they reach a consensus on the complexity.
This process allows for a tacit buy-in among the team members on the complexity and time for development for each story.
Stories are then clubbed together to form the first sprint of two-weeks. The team does this by estimating how many stories can be taken up for done-done delivery to client by the end of the two weeks. They base their estimates not on hours and tasks, but just on past experience of how much they can take on and deliver. [Task & hour based estimates are done later.]
The team does this for about two sprints, and takes an average of the story-points (complexity) they can deliver within a sprint. They total the story-points for the remaining backlog, and estimate the number of sprints it would take the team to build the product.
This effort gives a fairly good range of the project costs to the client for budgets approval. Such estimates and work with product backlog raises the project success rate.
We recommend our customers to have a budget higher than the estimates to accommodate for change requests, additional feature requests, and any unforeseen circumstances leading to project time escalations.