Advanced Topics In Scrum » task

Can work be added during a sprint?

Doug Shimp — Sat, 10 Oct 2009 02:34:36 +0000

You should never add work during a sprint
If the Product Owner wants it then put it in
As we understand the work we adjust our view of the work to reflect what it takes to do the job
This is really a question of granularity. If the adjusted work is in small bits then yes, as the bits get larger we risk loosing rhythm and consistency.
Our sprint plan should have nailed it. Changes during the sprint is a sign of sloppy planning.

Comment: Changes to work forms an interesting tension. At a fine grained detailed level it changes all the time. Each person’s individual to-dos often change to reflect their understanding of what it takes to get the job done. As the level of granularity increases to task then it is a change to the team’s plan. If the number of changes is significant and adds up to more than one story’s worth of work then you better stop and adjust your plan, usually you want the product owner in on that discussion. And if there are several new stories that were suddenly found and are so important they must be done right now, then call a stop and reset your entire sprint with a sprint planning session. Generally, the commitment by the team to the sprint should not change. Note: definition of team makes this an interesting discussion. Bottom Line: The goal here is to help the team get better at expressing work they can do and following through on a commitment.

Terms for the Work We Do

admin — Sat, 06 Jun 2009 15:03:26 +0000

The purpose of scrum is to develop product, often software and other ancillary products based on items in the backlog. In order to talk about this work we use lots of different terms when talking about backlog items, such as capability, feature, story, task, and so on. In this chapter we will define the terms that we use in this book, and have some discussion about the differences and nuances.

In particular, we will discuss the following terms: capability, chore, story, epic, and task. There tend to be natural comparisons and pairings in this set; for example, capability versus chore, stories versus epic, and story versus task. Each of these issues will be discussed as we go along.

But first, a quick review of fully know about Backlog Items, or PBIs. Basically a backlog items is anything the lives on the backlog; it can represent work to be done, issues to be discussed, or problems that we have. In any case, a backlog items is a token for future conversations, that progress from the moment we know about the backlog item until the work it represents has either been completed or discarded.

Short for “Product Backlog Item” – its original name. We keep the “P” because we love Three Letter Acronyms (TLAs).

This was derived from the use of stories, and we think it is a universal concept.

Our Glossary of Agile Terms

Task

admin — Thu, 04 Jun 2009 04:08:31 +0000

Tasks are the actual units of work the team does when working on a story in a sprint. The story is the item of planning and negotiation, but team often break stories into tasks in order to manage their work. We will seldom discuss tasks in this book, as the internal workings of the scrum team aren’t this book’s main focus.

The tasks for a story are “owned” by the team; the team commits to stories, not tasks. The tasks only exist to aid the team in its development efforts – it is the “doneness” criteria that define the “contract” for the story, not the tasks. Generally speaking, it is nobody’s concern except the team’s who works on what task, or even what the tasks are.