The Scrum approach to agile software development marks a dramatic departure from waterfall management. Scrum and other agile methods were inspired by its shortcomings. Scrum emphasizes collaboration, functioning software, team self management, and the flexibility to adapt to emerging business realities.
Scrum teams know that velocity is a rough estimate for the amount of work that a team can accomplish in a given sprint. It is calculated by simply adding up all the completed story points. Since the point values are merely estimates of the perceived difficulty and time necessary to complete the backlog item, a team’s velocity is not especially useful in and of itself. Instead, it becomes a valuable metric over time as teams complete multiple sprints and have the opportunity to establish a consistent velocity. Once this occurs, the Product Owner can look to the team’s established velocity to determine how much work it can tackle in the next sprint.
Amr Elssamadisy has just posted on the topic of velocity and concludes his post with the following questions: “Should velocity be used a metric for productivity? Should it be used for iteration planning? What about longer term release planning? Should it be used at all, or is it a wasteful practice?”
As always, I’m curious to hear how you’d answer those questions, so please share your thoughts in the comments section.
As you might guess, I’m of the mind that tracking velocity is a valuable process. However, the limits of its value must be understood, since it is derived from estimates (i.e. abstracted valuations) and not an absolute indication of progress or productivity. Thus, it can be helpful for sprint and release planning, but should be regarded as an estimate all the same.Perhaps the most valuable aspect of tracking velocity is the ability to observe how a team develops over time. That is, if a team consistently increases its velocity, it can be inferred that the team is learning to work together better and incrementally improving its performance.
To see an example of a team computing velocity, pay attention about halfway through this example Sprint Review Meeting.Tags: Scrum Methodology, Scrum Sprint Planning
Posted by admin under Scrum Discussion
As some of you might know, one of the biggest influences on the development of Scrum project management is complex systems theory, especially in relation to adaptive life forms. That is, just as life forms have adapted to survive in evolving conditions throughout history, Scrum teams also adapt to real-world business conditions to remain competitive and “survive.” Interestingly, several Scrum experts have commented that the Scrum framework will not evolve—that its current construction is stable to endure as-is. In my mind, such an assessment seems not only short-sighted, but deeply contradictory. If the process is based on continual improvement and adaptation, why wouldn’t the framework itself be subject to the same kind of survival-motivated revisions?
I was pleased, then, to find this blog post by Certified Scrum Trainer Dr. Dan Rawsthorne, PhD, which charts the evolution of Scrum from its early days to the present and wonders where it might head next. Certainly, he’s been on the scene since the early days and has a great perspective, but, for the most part, he doesn’t really commit to any predictions about how Scrum will evolve. It’s something I think about every day as I run up against certain shortcomings at the organization and wonder if it’s the framework itself or simply impediments derived from the people working within it. And it’s definitely something I’ve been thinking about more as organizations (my own included) wrestle with scaling small-team Scrum for the enterprise.
What do you think? Will Scrum continue to evolve or is the basic framework set in stone, with no reason to adapt beyond its current state? If you do think it will continue to evolve, how so? Please post your Nostradamus-like predictions in the comments section.Tags: Scrum Basics, the scrum future, where is scrum headed
Scrum Training Series
- Scrum based funding model – 20 percent May 9, 2013
- The Next Big Idea March 5, 2013
- On Being Available February 17, 2013
- Should Scrum Always Require the Product Owner to Attend the Sprint Retrospective Meeting? February 5, 2013
- Happiness Metrics January 23, 2013