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.
Posted by admin under Scrum Basics
In Scrum, some Product Owners would never deem a team’s work truly done without consulting the story’s acceptance criteria. Acceptance criteria are the requirements that have to be met for a story to be assessed as complete.
So what happens when only some—most, even—of a story’s acceptance criteria is met? Should the item be declared partially complete? No, what’s not done is not done. (Many ScrumMasters won’t allow teams to present work that hasn’t been completed.)
Why does Scrum only accept work that is 100 percent complete? First of all, an implicit acceptance criterion of any story is that it must be completed during the sprint it was negotiated. Work is confined to the sprint, so a team tries to complete the work in that sprint as well. Second, it’s common for teams to discover the final one percent of work to be more challenging than they expected. Third, when a Product Owner declares something done that isn’t, it results in velocity inflation, rendering the team’s velocity an unreliable metric for forecasting. Furthermore, when something is declared done without great rigor, a team has to play catch up, which often leads to a team falling behind and accruing substantial technical debt along the way.
A weak definition of done only serves to undermine a Product Owner’s ability to forecast accurately and risks building technical debt.
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