Friday, September 24, 2010
As I start talking about Agile and Scrum, I'm beginning to use the specialized terms associated with them. But as I mentioned in the last post, failing to have a clear mutual definition of terms can lead to fundamental errors that can be very difficult to correct. So -- here is what I currently understand to be the meanings of these terms. I would love to get clarification, disagreement, elaboration, or other commentary -- I'm at the very beginning of this learning curve, after all!





































AgileA philosophical approach to project management, and particularly to software development project management, that emphasizes the importance of human interactions and collaboration and responsiveness to a changing environment. The goal of an Agile approach to software development is to create a strong collaborative team including traditionally isolated functions (development, QA, customer) as integral members, encourage that team to direct itself in response to the customer's needs and priorities, and produce complete, useful, working software as quickly and frequently as possible. One reason for the goal of frequent software releases is that the quick turn-around time for development means that feedback occurs on a much faster cycle, and errors or misunderstandings are corrected promptly, saving time and effort in the long run.
IterationA single development cycle of one to four weeks, at the end of which some amount of complete and working software is presented to the client. Changes to priorities or designated goals are made between, not during, sprints, unless a change is sufficiently important to justify ending the iteration early.
ScrumScrum is an approach to software development that relies on empirical feedback during the development process to fine-tune and improve the choices made during development. The goal of Scrum is to "guide work toward the most valuable outcome possible." [Schwaber, Ken. Agile Project Management with Scrum, Washington: Microsoft Press, 2004. p. 2.]
SprintA Scrum take on an Iteration: because a Sprint includes formalized, heavy-weight planning and review (typically a day each), a scrum is typically two to four weeks, rather than one to four.
Product OwnerThe person responsible for setting the priorities so that they're consistent with the needs of the business; this is the person who represents the interests of the business and (if they're different) of the customer.
Scrum MasterIt's almost more important to say what the Scrum Master isn't. The Scrum Master is not a project manager, is not responsible for assigning work, is not responsible for setting priorities. A Scrum Master has two major responsibilities, and those are quite enough to keep anyone busy: 1. Enforce Scrum practice. 2. Clear bottlenecks and roadblocks. The Scrum Master doesn't set priorities, but does ensure that a kickoff meeting is held for the sprint, and that the product owner works with the team at that meeting to set priorities for the sprint. The Scrum Master doesn't assign work, but does ensure that the daily standups are held and are useful for ensuring that everyone knows what work is getting done and where help may be needed. Managing the Scrum process and removing the team's roadblocks are the responsibilities of the Scrum Master.
Product BacklogThe Product Backlog lists the requirements for the product or system being developed. However, rather than being a complete list of requirements established and sealed at the beginning of the project, the Product Backlog is a dynamic list of the functional requirements, performance requirements, etc., that is expected to change over the course of the project. The Product Owner is ultimately responsible for the maintenance and prioritization of the Product Backlog, but the whole team contributes in analyzing the items in the backlog and providing relevant information about each. During a specific sprint, the backlog should not be changed; but at the beginning of each new sprint the product backlog must be revisited as the priorities for the upcoming sprint are determined.
User StoryA user story is a way of framing a specific requirement such that it clearly reflects the end user's interest in the feature in question. It should consist of only one or two sentences -- certainly small enough to fit on an index card. They're often phrased as "As a [role], I want to [task], so that [benefit]." -- for instance, "As a blogger, I want to save a draft post without publishing it, so that I can close my browser without losing my work." Sometimes the "so that..." is taken for granted - "As a user, I want to be able to log in to the system" doesn't really need "so I can use it" tacked on -- but (see the previous post) I'd always rather see it included than left out, if there's any doubt.
Story PointsStory points are a way of allocating "level of effort" to a story without connecting the effort to an explicit time frame -- rather than saying a task will take seven days, or three hours, or a month, you assign it a number of story points. (This apparently becomes clearer and easier to do with practice.)


So - that's how I'm currently using these terms, when they show up in what I write. Disagreement? Elaboration? Commentary? Comment, please!
[and thanks to Mickey Phoenix for his clarifications!]

1 comments:

walker said...

I would point out that absent from the definition provided for both a sprint and iteration is the concept of a fixed timebox. While the duration of either may vary between teams and projects, a central point is that they do not vary for a team on a single project. This rule is what forces hard choices about what fits within a fixed-size box.

I've been working as a technical writer, business analyst, and project manager for more than twenty years. I've worked on many projects in many industries, and I've come to believe that the top-down culture and the CYA process design that's common to many companies regardless of size is profoundly counterproductive, and I'm looking for ways to change that culture and those processes.

In looking for a different way to organize people and projects, I found the Agile Manifesto. The Agile principles of valuing human interactions, collaboration, and openness to change sound wonderful; the focus on sustainability, simplicity, self-organization, and flexibility sounds good too.

I'm starting to study Agile; I'm taking a two-day class in October 2010, and planning to begin an Agile Management program at Berkeley in November 2010. I'll be talking about what I'm learning as I learn it; comments, feedback, questions, and advice are all very welcome.