#Velocity Archives

I believe that this quote can perfectly relate to the thought that I would like to express in this blog post about estimation in Agile. To some extent I feel that Agile nature also reflects the same behavior that you should be at-least at the edge of right instead of totally wrong, with respect to either decision making or estimation.

Here I would like to focus on Estimation, which is a very crucial part in every project. Agile has changed the concept of estimation. In traditional software development methodology, management used to estimate the project whereas in Agile, team together does the estimation of a project. Agile has introduced simple techniques for estimation – Planning poker and T-shirt sizing.

Planning poker technique has made estimations more simpler and less pressurized. Team generally uses
Fibonacci series as story points. Agile promotes standard Fibonacci series like 0 1/2 1 2 3 5 8 13 20… Fibonacci series looks like a progress bar growing from lower to higher range in terms of three factors:

Risk, Effort(not in terms of hours or days- it should be relative comparison of efforts with every user story) and Complexity.

While estimating user stories on the basis of these three factors, team makes sure to consider development, QA, Research and all other dependent tasks. All this estimation activity is done during the backlog refinement meeting.

From the bunch of user stories provided by the product owner (PO) for estimation, team first selects the easiest user story to start with and assign story points to it. Every person in the team show his/her story points for that user story. In case of differing opinions for story points between team members, they come up for discussion and present their view points for selecting that particular story point number. After discussing that user story from all the aspects team re-votes for that user story and keeps repeating the same process until all the team members converge on the same story point number, effectively agreeing on the scope and impact. And this way it becomes the benchmark for other user stories.

After analyzing the easiest user story team starts picking up the user stories from top to bottom
considering they were arranged priority wise by the Product Owner. And team finishes discussion on all those bunch of user stories given by PO. This way team ends up allocating the story points to all the user stories.

Velocity- After the team is done with estimation, during sprint planning the team decides how many story points they can pick during this sprint. Like wise team increases or decreases the story points in further sprints till they come up with the number of story points team is comfortable in picking up for the sprint. And from the experience, team keeps on improving their estimates. After two or three sprints average of story points can be considered as the velocity of the team which can be directly related to the performance of the team.

T-Shirt sizing – This is almost similar to planning poker but the only difference is instead of Fibonacci series team take sizes of t-shirts for estimation like XS, S, M, L,XL. Rest of the method of picking-up the sizes is same as in planning poker.

Team discussion on every user stories and PO presence in backlog refinement tremendously helps the team in understanding the requirements much better. Each individual’s input is important to make the estimation better and help in understanding the requirement correctly.

P.S- You can install the free “Scrum Poker” application from application stores for Android, iOS and windows smart phone which provides virtual story point cards for estimations.

Developing a quality software product falls under the realm of software engineering. The ever changing user requirements and harsh project timelines pave way for cost overruns or delays in the delivery schedule. So, bigger the scope of your project, more complex the functionality becomes. With so many factors it is very easy to lose control over the quality processes to develop an excellent product. We know that no engineering is complete without accurate measurements; which further brings us to the point that all measurements are done by applying certain metrics.For this reason we need software metrics for transparent and quality delivery of the product. Because when you measure what you speak about, you have numbers to express your failure or success. You have a calculated expression which shows you where you lacked and places you stood well. In Bob Parsons’ words-‘Anything that is measured and watched, improves.

Now the question arises- which software metrics to use?

One option is to pick a set of predefined metrics. The other one is you can first define the product requirements, discuss with the various stakeholders and then set the required metrics.

For a better understanding, consider an analogy when you are backpacking for an adventure activity. Would you pack a parachute if you are going for kayaking?

Absolutely not.

Instead, you would first decide upon the adventure sport, do a bit of research and accordingly pack your adventure gear. So, if you are going for paragliding, pack your bag with a helmet and a harness.

You can leave the oars behind for the next time.

Defying the law of gravity? It’s okay. But make sure you don’t cause more harm than good in the project. For this reason, it is important to apply the right metrics at the right stage in the product development cycle. As a software development company which builds engaging products.

1. Team Velocity Points

In simple words, team velocity measures the average speed of your team towards achieving its goal during one sprint. The fact that a typical sprint goes on for about 2-4 weeks, calculation of team velocity points proves to be a valid metric to gather the team’s efficiency.

If you want to calculate your team’s velocity, sum up the story points that were completed during that Sprint. To decide the team’s velocity, a three sprint’s average is usually considered.

Why? It’s an industry standard and it determines the project’s pace at which the functionality is being developed. In simple terms, it tracks the velocity of a Scrum team over time. This metric helps in deciding whether the team can take up more work over time or is the team already overloaded and it need to be reduced.

2. Sprint Burndown

Sprint burndown chart is the most effective tracking metric to visualize the health of the project. It helps in reviewing how much work is pending and if the team needs to speed up or slow down. You can also predict the expected completion date of the sprint. A deviation from the expected burndown will send a red flag to the scrum master to take appropriate actions.

For instance, if burndown goes up at any point during the sprint, it reflects an addition to the existing scope. At this time, it’s important for a team to achieve ‘team’s goal’ first before fetching new items from the backlog.

Why? The Burndown chart indicates the progress of work within a sprint. It shows whether amount of work a team is accomplishing every day will lead to a successful sprint completion or not.

3. Release Burnup

Product owners need to evaluate what should be out in the market first based on their discussions with other stakeholders. Release Burnup helps POs to continuously prioritize product backlog based on how the work is progressing.

If the release date is fixed and there has been a few additions to the initial scope, this is an important metric to align scope with the actual release date by either removing low priority backlog items or attempting to increase velocity by taking suitable measures.

Why? The Release Burnup chart indicates whether the sprints are progressing towards a successful project completion in terms of functionality achieved. Also, gives us a projected date of completion of the project.

4. Estimated Cost vs Actual Cost at Completion

Often there are gaps between the estimated cost projection during the start of the project and the actual cost at completion of the project. This metric gives a measurement of what deviations could have led to this difference in the cost.

Although, almost always the project cost goes higher than the expectation (just like we tend to overspend while shopping), this metric helps you understand what could be the possible cause of cost overrun- be it some design error or some changes in the scope of product development.

Why? Helps us understand what cost we had estimated and what cost was incurred. This helps us in improving our planning.

5. Number of major bugs per sprint

The number is an indicator of the overall quality of the product. When you are working in an agile project, it becomes important to put a budget i.e. count on the number of major defects open in a project at any point of time.

How can we stay within the budget? Reduce the count of defects reported.

How can we reduce the number of defects? Do Not Report!

Yes, I’m kidding.

Here is a better solution- focus at the time of planning, look-ahead and clearly define acceptance criteria before jumping on a sprint backlog item.

The priority of resolving any major bug is over and above implementing any new feature. Because if you can’t resolve what your did wrong, you can not pick a new feature.

At the same time, keep a close watch at the number of bugs reported after production release. If you have not been proactive in refactoring and improving quality of your code, chances are you will receive nasty numbers in this metric. This will help you to identify gaps in testing and take corrective measures

Tag: #Velocity

Effort Estimation in Agile