Breaking your project into Iterations and getting regular feedback on the iteration is the essence of Agile. In simple terms, velocity in an agile world is the amount of work that you can do in each iteration. This is based on experience from previous iterations. As you move over time and do multiple Sprints, the Velocity will be a very useful tool that will allow you to plan and predict the amount of work that the team can do in future Sprint cycles. If your team has completed multiple sprints, you can forecast release and product completion dates and plan future projects more accurately by reviewing the velocity report. Based on the velocity of previous sprints that the report illustrates, you can accomplish the following goals: track how much effort your team has reported as complete for each sprint and estimate how much backlog effort your team can handle in future sprints if your team composition and sprint duration stay constant.
Scrum is a framework for running projects that is based on agile principles and values. It defines a set of activities that can help your team deliver more value to your customers faster. These activities provide your customers with the opportunity to review, guide and influence your team's work as it progresses. This approach does not attempt to define everything at the start of a project. Instead, your team works in short iterations (also called sprints) and refines the plan as the team makes progress. For information about the agile principles and values on which Scrum is based.
In order to get to an actual number, you need to look at the estimates from your previous iterations. So let’s say you had the following stories and estimates below;
- Story 1 – 2 Days – As a Manager, I want to see all Sales for the month, to aid in planning.
- Story 2 – 3 Days – As a User, I need to change my password, to protect me from fraud.
- Story 3 – 1 Day – As a User, I want to see all previous purchases, so it is easy for me to reorder.
In these 10 posts, I outline specifically how to implement Scrum in 10 easy steps:
- Step #1: Get your backlog in order!
- Step #2: How to estimate your product backlog
- Step #3: Sprint Planning/clarify requirements
- Step #4: Sprint Planning/estimate tasks
- Step #5: Create a collaborative workspace
- Step #6: Sprint!
- Step #7: Stand up and be counted!
- Step #8: Track progress with a daily burndown chart
- Step #9: Finish when you said you would
- Step #10: Review, reflect, repeat…
Software Development, and how it fundamentally differs from a more traditional waterfall approach to software development, are as follows:
1. Active user involvement is imperative
2. The team must be empowered to make decisions
3. Requirements evolve but the timescale is fixed
4. Capture requirements at a high level; lightweight & visual
5. Develop small, incremental releases and iterate
6. Focus on frequent delivery of products
7. Complete each feature before moving on to the next
8. Apply the 80/20 rule
9. Testing is integrated throughout the project lifecycle – test early and often
10. A collaborative & cooperative approach between all stakeholders is essential
You can develop complex products by using the Scrum framework, which is based on agile principles and values. For more information, see Scrum and Agile Principles and Values, by Jeff Sutherland. However, Velocity also means that you are looking forward, not looking at the amount of work that employees are actually doing; so if that means that an employee spent night and day resolving some complex issues, in terms of Velocity, it will be defined as a reduction of the amount of work required (and you might not even credit the employee for the amount of hard work required to get the work done as per time and schedule).
So why is it important?
After you do a few iterations, you will become better at estimating and your velocity should start to stabilize. With a stable velocity, planning releases and iterations becomes much easier. Management and the business are also loads happier as you are delivering standard size iterations with less surprises. Velocity calculation with story points is a statistical way to measure progress since you don’t have to guess right on every story, the important thing is that you do the same type of guessing with the same prerequisites and facts every time. Then velocity is what you measure it to be, there can be no tweaking or hoping.
Determine Your Team's Velocity
Before your team creates its release plan and plans each sprint, your team must determine its velocity. Your team's velocity is the number of story points that it can complete in a sprint. If historical data is not available, your team can make a rough estimation of how many story points it can complete in the first sprint. Look at the estimated user stories at the top of the priority stack and make a quick assessment of how many stories it could complete in a sprint. Add the story points for each of those user stories to get an initial estimate.
After the first sprint, you can use historical data to determine your team's velocity. In the first few sprints, you should expect substantial variation as your team learns how to estimate consistently. Over the course of several sprints, your team's measured velocity should become more stable. When your team's measured velocity is stable, reassess the release plan.
= Number of total story points / One iteration.
Velocity is a measurement of how much the team gets done in an iteration ( called as Sprint in Scrum ). Velocity is what actually got done in the last iteration not what is planned. In Scrum it is measure in Story points. Each feature in scrum is a story. A story has points. Points can be anything you come up with. Examples are 1, 2, 4, 8 , 16 5, 10 15 and so on. A story depending on its complexity is given certain story points. So if the team does 6 stories that are 8 story points that iteration , the teams velocity is 48 story points.
Engeneering best practices to increase Velocity:
Build and deploy continuously: If a team waits a long time between checking code in and deploying a build, members of that team frequently spend a significant amount of time addressing build breaks and integration issues. If your team checks code in and builds more frequently, you can generally expect to increase your team's velocity. Branch Strategically: Branch strategically: Your team can create and use branches in version control to optimize your application development strategy. Test Early and Often: Test early and often: Your team can verify that it is creating the software that its customers need by effectively testing its work. Your team should start to test early and test often as the code is built. At the start of a sprint, your team should create the test plan for the sprint. That test plan can use test suites that organize the tests in a way that helps your team run them and track the results. Model your application: Your team can use models to explore and refactor existing code, to understand your customers' needs more effectively, to help determine and communicate your software design, and to inform the development of acceptance and component tests.
Scrum is about the process, not the tools. Make very sure that everyone involved (not just the development team!) understands what Scrum is about. It's not just working iteratively in 2 week sprints. It's about commitment from management about this way of working. It's about having a very good product owner that can set priorities. It's about being open to each other within the team.
References
Scrum by Microsoft
Engineering Practices
80+ Agile and Kanban tools. Feel free to check it out: http://agilescout.com/best-agile-tools
How To Implement Scrum in 10 Easy Steps
There is also a really good site with many advices about how to begin with scrum: implementingscrum.com
Scrum Terms
Definition and Calculation:
Velocity is calculated based on the number of "story points," "tasks," or any other unit of measure the team uses, completed in previous sprints. For example, if a team completes 20 story points worth of work in one sprint and 30 in the next, their average velocity would be the total completed story points divided by the number of sprints (in this case, (20 + 30) / 2 = 25 story points per sprint).
Purpose and Usage:
-
Sprint Planning: Velocity helps teams make informed decisions during sprint planning. Knowing their velocity, a team can select a realistic amount of work from the product backlog for the next sprint, aiming not to overcommit or undercommit.
-
Predictability: Over time, a team's velocity may stabilize, allowing for more predictable sprint outcomes and better long-term planning.
-
Improvement Measurement: Teams can use velocity as one of many metrics to measure their efficiency over time. If changes are made to processes or team composition, velocity can help gauge the impact of these changes.
Considerations:
-
Team-Specific: Velocity is unique to each team because each group may estimate and complete work differently. Therefore, it should not be used to compare the performance of different teams.
-
Not a Measure of Value: While velocity can indicate how much a team can do, it doesn't necessarily reflect the value or quality of the work completed. Teams should ensure they're not just completing tasks but are delivering value.
-
Can Change Over Time: Various factors like team composition changes, different types of work, and external factors can affect a team's velocity. It's normal for velocity to fluctuate.
-
Not a Target: Velocity should be used as a planning tool, not a target to be hit or exceeded. Pushing teams to increase their velocity artificially can lead to burnout or reduced work quality.
In summary, velocity in Scrum projects is a reflection of the team's past performance and a tool for future sprint planning. It helps teams gauge how much work they can realistically achieve in a set timeframe, aiding in better decision-making and project planning.
Summary
To increase the velocity at which your team delivers value to your customers, your team can apply engineering practices that come from agile methodologies and that support agile principles and values. Good questions to ask your team: How much effort has your team completed in each sprint? What is the maximum velocity of your team? What is the minimum velocity of your team? What is the average velocity of your team? What is your answers on questions above?
Best articles: .NET Web frameworks, IOC pattern, IT articles, VS 2010 Tips.