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 waterfall, managers determine a team member’s workload capacity in terms of time. Managers ask selected developers to estimate how long they anticipate certain tasks will take and then assign work based on that team member’s total available time. The downsides of traditional estimation are well known: work is always late, there are always quality problems, and there’s always a last minute crunch to meet the deadline.
Scrum teams take a radically different approach. First of all, entire Scrum teams, rather than individuals, take on the work. The whole team is responsible for each Product Backlog Item. The whole team is responsible for a tested product. There’s no “my work” vs. “your work.” So we focus on collective effort per Product Backlog Item rather than individual effort per task. Second, Scrum teams prefer to compare items to each other, or estimate them in relative units rather than absolute time units. (Ultimately this produces better forecasts.) Thirdly, Scrum teams break customer-visible requirements into the smallest possible stories, reducing risk dramatically.
Anxiety about estimation usually means the organization is not strong in the other Agile practices, particularly Test Driven Development (TDD). Scrum requires that the product be kept in a potentially shippable (e.g. properly tested) state every Sprint, that the Product Owner declares which work is top priority, and that work be split into thin vertical slices, typically customer-centric user stories no greater than a few days each. If we’re doing the other Agile stuff right, the only downside of getting estimates wrong is that we’ll ship on time while omitting the less important features — a far less stressful way to live than what waterfall or pseudo-Agile teams are experiencing today.
What does the process of estimation look like? Scrum does not prescribe a single way for teams to estimate their work. The only estimate that’s defined by Scrum is whether a team will attempt a PBI this Sprint or not, as decided in the Sprint Planning Meeting. Common estimating methods include t-shirt sizes (S, M, L, and too big), powers of 2 (1, 2, 4, 8), the Fibonacci sequence (1, 2, 3, 5, 8, 13, etc.). In recent years, teams subscribing to the #NoEstimates philosophy simply make all stories as small as possible.
In the Backlog Refinement Meeting, the team sits down with the Product Owner to discuss the stories toward the top of the Product Backlog. The Product Owner often wants effort estimates to help evaluate ROI, effectively prioritize items in the Product Backlog, and predict which items will be ready by a given release date. So the Product Owner wants an honest appraisal of how difficult work will be.
To gather a cross section of viewpoints despite the different personalities on a team, it is often recommended that all team members disclose their estimates simultaneously. Individuals “show their hands” at once, inspiring the term “planning poker.”
Even when teams possess a shared understanding of their scale, individuals will usually choose different cards. This should trigger discussion of the implementation approach, clarification of the requirement with the Product Owner, and splitting the requirement into smaller stories (some of which will be lower priority). Often several rounds are necessary to arrive at a single effort estimation that reflects the entire team’s sense of a story’s difficulty. The refinement and clarification is more important than the estimates themselves.
Need an example? Watch an example team conduct a Backlog Grooming Meeting, including relative estimation and example user stories. Planning poker is demonstrated at the 4 minute mark of this video:
To see how velocity is computed from story points, watch an example Sprint Review Meeting including velocity measurement.
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.Tags: Acceptance Criteria
Posted by admin under Agile and Scrum
Here’s an interesting video I reposted from the Agile Journal website: an interview at the Agile 2008 conference in Toronto between Agile Journal reporter Patrick Egan and Victor Szalvay, co-founder of Danube Technologies, Inc. and Product Owner for the ScrumWorks Pro agile management tool. It only clocks in at about five minutes, but, in that time, Patrick and Victor cover a lot of ground. Topics discussed include agile adoption trends; the evolution of agile tooling solutions; common challenges organizations face when adopting agile; and how Danube uses Scrum to manage all their projects, from budget forecasting to marketing.Tags: Agile Conference 2008
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