0

After stopping our current sprint we need to move a lot of items to the next sprint. This raised some questions where we, as new scrum users, did not find an answer to.

We understand that we need to create new PBI's and move the tasks which are marked as To Do to that newly created PBI. (And what happens with In Progress tasks, how should they be moved? Just move them, or close them and create a new one for the new sprint?)

One of the discussions raised was how we should name our PBI's because the management wants it to be clear enough for our customer who has read access to our Product Backlog and the Sprint Backlog.

From a developer point of view, PBI's such as "Research feature A", "Implement feature A", "Polish feature A", while our management believes the PBI's should be named "feature A (part 1)", "Feature A (part 2)", "Feature A (part 3 - END)" because neither they nor our customer understands our PBI's and they want to know when they can start testing feature A. Our management basically just wants to print out the Sprint Backlog query and pass that on to our client as a way of showing what has been done.

A second, less important, question is: how should we properly use the area path? If we have a feature A, it makes sense to us to create a feature A area path and use that as a common identifier for all PBI's and tasks which are related to it. But what should we do with work items that are related to multiple features (and thus area paths)? We are afraid we would end up with lots of area paths and the list would get cluttered. We can't remove area paths because bugs might be filed for it, or we need to pick it up at a later stage. Also, what if a feature has the be implemented in multiple versions of the application?

Vadim Kotov
  • 8,084
  • 8
  • 48
  • 62
Jensen
  • 3,498
  • 2
  • 26
  • 43

1 Answers1

1

We understand that we need to create new PBI's and move the tasks which are marked as To Do to that newly created PBI. (And what happens with In Progress tasks, how should they be moved? Just move them, or close them and create a new one for the new sprint?)

You don't need to create new PBIs for each sprint! A PBI stays in progress until all its child tasks are done. Its iteration may move forward to the next sprint (e.g. "Release 1\Sprint 1 > Release 1\Sprint 2" or just stay on an upper level ("Release 1"). Tasks don't get moved to another PBI, but do get progressed to the next sprint.

This will resolve the naming issue, as PBI's wouldn't get the "part X" suffix. A possible name for PBI is "Feature A - infrastructure" or "Feature A - UI". So its child tasks may be named "Feature A - infrastructure - design", "Feature A - infrastructure - implementation" and "Feature A - UI - design" and so on.

A second, less important, question is: how should we properly use the area path?

If Iteration is a chronological point in time, so Area is used to represent a logical module of the product. E.g.:

|-Server
| |--Database
| |--Web Services
|
|-Client
| |--UI
| |--Navigation
|
|-Configuration
|
|-Documentation
|
|-Installation
| |---Client
| |---Plugins
|

Don't overuse area definitions. The list should be clean and easy to understand.

what if a feature has the be implemented in multiple versions of the application?

Create another PBI and assign it with the same Area path but different Iteration path.

KMoraz
  • 14,004
  • 3
  • 49
  • 82