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.


Complexity and cost of change

Posted by admin under Agile and Scrum, Scrum Basics, Scrum Discussion

There are many variables to estimating the difficulty of a code changes. We could talk about things like the complexity of the code (Cyclomatic Complexity), the experience of the programmers, their familiarity with the topic and/or the specific module, the quality of documentation, etc. It ends up being a fairly subjective estimate. In Scrum teams, story sizes are estimated in relative terms in terms of story points.

The primary benefit to using a technique involving Relative Estimates is that you are asking the team to give you an estimate of difficulty relative to other work that has already been completed. This means that a team can easily give judgments like “This will be twice as hard as that” and come up with functional estimations for predictions without spending a great deal of time coming up with them. Estimates are just subjective guesses anyway, understanding that can be a valuable way to put more time into building something and less time into trying to guess how much time it will be to build it. Planning Poker, also called Scrum poker, is one technique for building relative estimates and for coming to consensus on the effort or relative size of the stories.

Tags: , , , , ,


Estimating Earned Business Value on Agile Projects

Posted by admin under Agile and Scrum, Agile Manifesto, Agile Principles, Scrum Basics, Scrum Discussion, Scrum Transitions

A pattern I’ve noticed is that Scrum projects are typically managed informally, with the only measures used being various velocity metrics and burndown charts. This may be an issue. Many project managers and executives resist scrum because these only measure the speed of delivery, not the project’s cost or the business value it generates. One of the major differences between traditional and agile projects is that traditional projects focus on delivering software that satisfies requirements, while agile projects focus on maximizing ROI through continuous feedback and re-planning.

This is where Earned Business Value calculations come in. It fits well with Agile projects, since the focus of agile projects is on business value rather than conformance to requirements (outcomes over outputs). In many cases, EVM metrics are easier to calculate and understand in agile environments than in traditional ones. There are three key management measures – Cost Performance Index (CPI), Schedule Performance Index (SPI), and Earned Business Value (EBV) – that provide information to help manage an agile project from and ROI perspective.

There is a solid white paper on this topic at .

I’d also be very interested in your comments to this post.

, , , , , , , , , , , , , , , , ,


The Scrum Backlog

Posted by admin under Scrum Basics

Scrum has two types of backlogs, the Product Backlog, and the Sprint Backlog.

The Product Backlog is a prioritized list of customer-centric features. It breaks the big-picture vision down into manageable increments of work called Product Backlog Items (PBIs). These are typically expressed in user story form. Product Backlog Items are not tasks, they represent the what rather than the how. If Product Backlog Items are estimated, they’re estimated in relative units such as story points. Items toward the top of the Product Backlog should be small enough that a team could accomplish several of them (including proper testing, integration, etc.) in one two-week Sprint.

The Product Owner and Team collaborate to refine the Product Backlog continuously (e.g. about an hour per week) in the Backlog Refinement Meeting.

In Large Scale Scrum, multiple teams pull their work from a single Product Backlog. Multiple teams collaborate with the Product Owner to refine the single Product Backlog.

The Sprint Backlog is created during the Sprint Planning Meeting. The team pulls the amount of work they want to do from the Product Backlog into the Sprint Backlog, and further decomposes the PBIs into Sprint Tasks. The team decides the how, and expresses this in the tasks. The best way to represent the Sprint Backlog is a physical taskboard, using PostIt Notes or index cards. During the Sprint, typically at the Daily Scrum Meeting, team members move the tasks around to reflect how they’re doing on them. One purpose of the Sprint Backlog is to limit work in progress (WIP). Humans become ineffective when they worry about too many things at the same time.

Tags: , , , ,


Scrum Backlog Grooming

Posted by admin under Scrum Basics

While backlog refinement (also called grooming) was not originally a formal meeting in the Scrum framework, Ken Schwaber, who founded Scrum, advises teams to dedicate five percent of every sprint to this activity. As with Scrum’s other meetings, the grooming should take place at the same time and place and for the same duration each sprint.

Everyone attends the backlog refinement meeting: the team, the Product Owner, and the ScrumMaster. During the meeting, everyone helps prepare the Product Backlog for the sprint planning meeting. This usually includes adding new stories and epics, extracting stories from existing epics, and estimating effort for existing stories. Why is this helpful? Because a groomed backlog will help streamline sprint planning meetings; otherwise, they can stretch on for hours. When product backlog items contain clearly defined acceptance criteria and are estimated by the team members, the planning process does not have to be tense or overly long. By dedicating a time to backlog maintenance, the team ensures that this preliminary planning occurs prior to the sprint planning meeting.

Watch an example backlog grooming meeting.

Tags: , , ,

Scrum Training Courses