context.ExecuteCommand("DELETE FROM Entity");
Or
context.ExecuteCommand("TRUNCATE TABLE Entity");
Or
context.ExecuteCommand("TRUNCATE TABLE Entity");
Wednesday 23 November 2016
Agile FAQ
How is velocity of an agile development team calculated?
Velocity is the sum of the estimates of delivered (i.e., accepted) features per iteration.
Velocity is the sum of the estimates of delivered (i.e., accepted) features per iteration.
What unit is used to measure velocity?
Velocity is measured in the same units as feature estimates, whether this is story points, days, ideal days, or hours that the Scrum team delivers – all of which are considered acceptable.
Velocity is measured in the same units as feature estimates, whether this is story points, days, ideal days, or hours that the Scrum team delivers – all of which are considered acceptable.
How is the first iteration’s velocity estimated?
For an agile team’s first iteration, a general guideline is to plan initial velocity at one-third of available time. If you’re estimating ideal programmer time then this account for meetings, email, design, documentation, rework, collaboration, research, etc. As an example, with six programmers and two-week iterations, a total of 60 programmer-days (6 programmers x10 days) are available. In this situation, a good start would be to plan 20 ideal days worth of work in the iteration. If using actual time, include enough of a buffer to account for standard project 1) overhead and 2) estimation inaccuracy.
For an agile team’s first iteration, a general guideline is to plan initial velocity at one-third of available time. If you’re estimating ideal programmer time then this account for meetings, email, design, documentation, rework, collaboration, research, etc. As an example, with six programmers and two-week iterations, a total of 60 programmer-days (6 programmers x10 days) are available. In this situation, a good start would be to plan 20 ideal days worth of work in the iteration. If using actual time, include enough of a buffer to account for standard project 1) overhead and 2) estimation inaccuracy.
Also, remember that velocity will quickly emerge during the first iteration. If underestimated, velocity in the first iteration will rise as new features are included; and if overestimated, velocity will decrease as features are removed. For the second iteration the Scrum team should then use the first iteration as a guideline.
Do meetings, phone calls, email get included in velocity?
This depends on whether these items are estimated and included in the iteration plans. They are typically not included – a goal of velocity is relative consistency and predictability across iterations in terms of an agile team’s ability to deliver.
This depends on whether these items are estimated and included in the iteration plans. They are typically not included – a goal of velocity is relative consistency and predictability across iterations in terms of an agile team’s ability to deliver.
Should velocity be accumulated across all agile development teams or projects?
Velocity is very much a localized measure. In addition to different team members with different team ‘personalities’, projects typically possess unique characteristics in terms of estimating techniques, detail process, technology, customer involvement, etc. As a result, this can make organization-wide analysis very inaccurate. If, on the other hand, all of your teams estimate exactly the same, develop exactly the same, test exactly the same, and track exactly the same, then by all means, maybe you are the exception.
Velocity is very much a localized measure. In addition to different team members with different team ‘personalities’, projects typically possess unique characteristics in terms of estimating techniques, detail process, technology, customer involvement, etc. As a result, this can make organization-wide analysis very inaccurate. If, on the other hand, all of your teams estimate exactly the same, develop exactly the same, test exactly the same, and track exactly the same, then by all means, maybe you are the exception.
What if velocity fluctuates?
Velocity will typically fluctuate within a reasonable range, which is perfectly fine. If velocity fluctuates widely for more than one or two iterations, the Scrum team may need to re-estimate and/or renegotiate the release plan.
Velocity will typically fluctuate within a reasonable range, which is perfectly fine. If velocity fluctuates widely for more than one or two iterations, the Scrum team may need to re-estimate and/or renegotiate the release plan.
How long does it take for velocity to stabilize?
For most agile development teams velocity will typically stabilize between 3 and 6 iterations.
For most agile development teams velocity will typically stabilize between 3 and 6 iterations.
How do I estimate future iterations?
Future iterations use the proven history of the team to determine how much the team can do. Therefore, velocity is the right measure to use for planning future iterations.
Future iterations use the proven history of the team to determine how much the team can do. Therefore, velocity is the right measure to use for planning future iterations.
How do I estimate velocity if project teams change size?
Velocity relies on team consistency in order to be most valuable. If your agile team changes, use common sense in planning future iterations. If 20% of your team is unavailable for a couple iterations, then reduce planned velocity by 20% or so. If this includes a couple of key players, in particular a customer that may be less available, then reduce the estimate a little more. It will only take the length of the next iteration to understand better what the team can deliver and thus their new velocity.
Velocity relies on team consistency in order to be most valuable. If your agile team changes, use common sense in planning future iterations. If 20% of your team is unavailable for a couple iterations, then reduce planned velocity by 20% or so. If this includes a couple of key players, in particular a customer that may be less available, then reduce the estimate a little more. It will only take the length of the next iteration to understand better what the team can deliver and thus their new velocity.
Does maximum velocity mean maximum productivity?
Absolutely not. In an attempt to maximize velocity, a team may in fact achieve the opposite. If asked to maximize velocity, a team may skimp on unit or acceptance testing, reduce customer collaboration, skip fixing bugs, minimize refactoring, or many other key benefits of the various agile development practices. While potentially offering short-term improvement (if you can call it that), there will be a negative long-term impact. The goal is not maximized velocity, but rather optimal velocity over time, which takes into account many factors including the quality of the end product.
Absolutely not. In an attempt to maximize velocity, a team may in fact achieve the opposite. If asked to maximize velocity, a team may skimp on unit or acceptance testing, reduce customer collaboration, skip fixing bugs, minimize refactoring, or many other key benefits of the various agile development practices. While potentially offering short-term improvement (if you can call it that), there will be a negative long-term impact. The goal is not maximized velocity, but rather optimal velocity over time, which takes into account many factors including the quality of the end product.
How do we measure velocity if our iteration lengths change?
You don’t, at least not nearly as easily. Velocity’s value comes from its inherent consistency. A fixed iteration length helps drive the reliable rhythm of a project. Without this rhythm, you are constant revising, re-estimating, and reconciling, and the ability to predict out in the future is minimized due to inconsistent results. If, on the other hand, almost everyone is going to be out a week for the holidays or a couple days for company-wide meetings, then by all means simply use common sense and adapt iteration dates or velocity accordingly. Like most agile practices, these are guidelines, not rules that are meant to prevent common sense.
You don’t, at least not nearly as easily. Velocity’s value comes from its inherent consistency. A fixed iteration length helps drive the reliable rhythm of a project. Without this rhythm, you are constant revising, re-estimating, and reconciling, and the ability to predict out in the future is minimized due to inconsistent results. If, on the other hand, almost everyone is going to be out a week for the holidays or a couple days for company-wide meetings, then by all means simply use common sense and adapt iteration dates or velocity accordingly. Like most agile practices, these are guidelines, not rules that are meant to prevent common sense.
Velocity in Agile
Velocity is a metric that predicts how much work an Agile software development team can successfully complete within a two-week sprint (or similar time-boxed period).
Velocity is a useful planning tool for estimating how fast work can be completed and how long it will take to complete a project. The metric is calculated by reviewing work the team successfully completed during previous sprints; for example, if the team completed 10 stories during a two-week sprint and each story was worth 3 story points, then the team's velocity is 30 story points per sprint.
Generally, velocity remains somewhat constant during a development project, which makes it a useful metric for estimating how long it will take a team to complete a software development project. If the product backlog has 300 story points, and the team is averaging 30 story points per sprint, it can be estimated that team members will require 10 more sprints to complete work. If each sprint lasts two weeks, then the project will last 20 more weeks. If a team member is moved to another project, however, or new members are added -- the velocity must be recalculated.
Subscribe to:
Posts (Atom)