There's still some confusion out there about whether the Product Owner is a member of the Scrum Team. Rather than pile on the confusion, please stick to Ken Schwaber's terms: "Scrum Development Team" for the subset of the team that excludes the Product Owner, and "Scrum Team" for the dev team + ScrumMaster + Product Owner. These are defined by _The Enterprise and Scrum_ (Schwaber 2007).

I attended your training class a couple of months ago. We are continuing along with our scrum process, and we are learning a lot. I have one question - hope it is ok to ask. We did story point estimation as part of our team's Sprint planning, and came up with the total story points that we were going to tackle for the sprint. As we started working on some of the tasks, we realized that they were more difficult then we had originally estimated. Also, some people finished their tasks early and picked extra stuff from the backlog.

My question is as follows: Do you ever change the total story point value in the middle of the sprint (for either of the reasons that I mentioned above), and it if so, how would that work if your burn down is based on story points vs time. I know we talked about it in class, but I can't remember the answer.

I remember asking my own Scrum coach the same question a few years ago.

A Scrum Team is:

• A Product Owner
• A Scrum Development Team
• A ScrumMaster

Organizations that are looking for an automated tool to help manage Scrum fall along a continuum.

• At one end are the Scrum purists, who feel that resistance to doing real Scrum is an organizational impediment to be exposed and rooted out rather than accommodated as business as usual. These folks believe the highest performance and ingenuity comes from intense collaboration, small cross-functional teams lacking defined roles, self organization, face to face communication, and even a certain amount of chaos during Sprint execution. They typically prefer lightweight tools that make the Scrum artifacts visible without impeding team self organization.
• At the other end are those who want some version of the Scrum/Agile practices, but also feel "traditional" practices (such as Taylorism, waterfall, or parts of the PMBOK) would meet their current needs. They may be dealing with impediments to self organization, lack of co-location, suboptimal team composition, large departments, entrenched practices, regulatory requirements, etc. Or they may not be in a position to wait for teams to go through the "forming, storming, norming, performing" growth stages. These folks tend to request features that make the purists cringe.
• Some are in organizations that are transitioning from traditional practices to Scrum. Some skeptics I've known became full-fledged advocates after seeing results from pilot teams attempting uncompromised Scrum with good coaching.

I've collected a dozen Dilbert cartoons relevant to Scrum. This week brings us a couple cartoons depicting a dysfunctional daily Scrum (an exercise we sometimes use in class). Previous cartoons have lampooned user stories, working without plans or documentation ("Just start coding and complaining!"), and forcing Agile approaches from the top down.

In a discussion group, someone recently wrote:

From the very beginning, the PO has been very insistent that we use an electronic tool, despite the fact that everyone is co-located. I have resisted from the very beginning, because the Team feels that

People accustomed to traditional project management often want to know how Scrum deals with "risk management." An example of how many project managers think about risk management is on this page (highlighted in red even):

It is much better to reduce the risks at the start up phase of the project than to allow a contingency on a basis that things are bound to go wrong, but we don't know what!

That thinking is probably useful for traditional projects with known requirements and established technologies. Here's the bad news: When we're doing new product development (somewhat unknown requirements, somewhat unknown technologies), things are bound to go wrong, and we don't know what!

Depending what your risks are, doing Scrum well may help. Let's enumerate some typical risks:

Modern languages combined with the engineering practices derived from eXtreme Programming (Test Driven Development, constant refactoring, continuous integration...) make it possible to flatten out the pessimistic exponential "cost of change curve" we learned in the early days.

The ability to *do* this involves learning skills and habits your team may not have yet.

From the November 2007 issue of Fast Company: