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
Anxiety about estimation usually means the organization is not strong in the other Agile practices such as Test Driven Development (TDD). Scrum requires that the product be kept in a potentially shippable (e.g. properly tested/integrated) 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 bigger than a few days each. If we’re doing the other Agile stuff right, we cannot miss release dates because the product is shippable every week or two. The only downside of getting estimates wrong is that we’ll ship on time while omitting the less important features — a less stressful way to live than what waterfall or pseudo-Agile teams are experiencing today.
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. In waterfall, tests are done after coding by specific job titles rather than written in conjunction with the code. The downsides of waterfall are well known: work is always late, there are always quality problems, some people are always waiting for other people, 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. When there’s too much work for 7 people, we organize into feature teams to eliminate dependencies.
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, etc.), or simply small vs. needs-to-be-split (see #NoEstimates below).
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 useful for all team members to disclose their estimates simultaneously. Individuals show their cards at once, inspiring the term “planning poker.” 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 are more important than the estimates themselves. According to the Agile Manifesto, business people and developers must work together daily throughout the project.
In recent years, teams subscribing to the #NoEstimates philosophy have simply made all stories as small as possible. For #NoEstimates teams, the only estimate is whether a User Story is small. If it’s not small, they split it until it is small. Some of these teams still make forecasts by comparing completed stories over time to stories remaining in the release plan. The #NoEstimates approaches are gaining ground, but not universally accepted within the Agile movement.
Interfacing With Traditional Expectations
For techniques that may be more palatable to traditional managers, see Mike Cohn’s popular book Agile Estimating & Planning. Our own team used some of these approaches to make multi-month forecasts and release plans. They were still a bit off, but they were closer than anything I’d seen before. One thing that helped was doing everything possible to eliminate unnecessary unpredictability. Product development is ultimately about learning and creating, so some unpredictability is necessary. But unnecessary unpredictability can often be reduced by keeping the same team together, keeping the Sprint length the same, always building end-to-end integrated vertical slices, eliminating external dependencies, and using techniques like TDD to avoid surprise regression failures and interruptions. Bad code causes painfully unnecessary unpredictability in waterfall or Agile.
If you’re wondering how to make all this work with contracts, I’d urge you and your lawyers to read the Agile Contracts Primer.
About The Author
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