When to create PBI's from a feature request an

问题:

We are in the process of starting to use Scrum (in combination with TFS 2010 and the MS Scrum template) in our company. Since none of us have any experience there are still some questions to be answered.

1. Since our Product Manager and Scrum Master are non-technical people it would mean that we, the Developers will be part of the meetings that split up the feature requests in small Product Backlog Items. It is my belief that we can do this on our "planning poker" meetings to discuss the feature. But how is this planned in? Let's say that we get a new feature request in the middle of our sprint. (Our sprint will be 80/20 timed.) Should we keep this also into account when planning our sprint, or would it simply mean that the time we spend in that meeting must result in items moved back onto the Product Backlog.

2. We know we should split a feature up into as many PBIs as we can (and of course, that makes sense) and that a single PBI should not exceed the length of one sprint. That also makes sense. But where should we draw the line? For example, our application communicates with several USB devices. The feature request is that we should communicate with a new device. Implementing this is a 2 part job:

   a) add the communication with the device to our USB library;
   b) add UI support for this device

   Should we split this up into two separate PBIs, or is this one PBI of which we should create multiple tasks?

On a side-note: when a PBI has been added, should we create a task for each PBI when we start implementing it? As far as I see in TFS we cannot set remaining work hours on a PBI. So my initial idea was to create a task for each PBI. But I know some colleagues will find it "a lot of work" to create a task for a PBI that only has one task. How should we handle this?

回答1:

1. In Scrum, it is the PO's responsibility to break the features into small-enough user stories. That being said, there's nothing wrong with the PO getting help from the team (or anyone else for that matter) in splitting them. The planning poker session might be a good place to fine-tune the split, due to the team's input on the complexity of each story, but the PO should have a sense of how to split the stories beforehand.
2. The planning session should take roughly half a day. Definitely not a significant portion of each sprint. Regardless though, the remaining hours in the sprint (e.g. 90-5=85, in a two week sprint) should be the amount of time that the team has to fill with the stories' tasks. Of course, no matter how much time is left in the sprint, any stories that the team can't commit to should be returned to the product backlog; they won't be done in this sprint.
3. The stories should be sized appropriately, i.e. can be completed in a single sprint. Personally, I prefer to size stories so that a few stories can be completed by the team in one sprint. A good rule of thumb (but not a hard rule, by any means) is to stop splitting your stories when you reach the point that they can be released by the team in 3-5 days.
4. Though you didn't ask how to split your features and split them along the lines of Core capability, entry barriers, key differentiators, and nice-to-haves.
5. Regarding Breaking the stories into tasks: You should have at least one task per story. Stories define what needs to be done; Tasks define how. You should probably have at least one task per participating component of the system, as well as one task per actionable item in your definition of **done. If you have only one task, then you probably don't have a definition of done, or your stories are defining implementation, rather than functionality.

With regard to TFS - TFS doesn't change any of the above, though it does support everything I suggested.

回答2:

Yes, it's better if you create tasks under PBI even if its only one task, because the PBI was made to monitor product progress, it used story points in estimation (Relative Size), but the task is used to monitor work progress, it used hours in estimation, so every work items have different purpose.

回答3:

1) The time taken to split the stories out will be reflected in your team's velocity so you shouldn't really have to do anything to plan it in. If you are spending say, half of your sprint in story planning/splitting and getting 5 stories done per iteration, then your plans will reflect that. Through the use of retrospectives you can see that spending less time in story splitting will increase your velocity to say, 8 stories per iteration. Keep an eye out for side effects of spending less time splitting stories though so you can see both sides of the coin.

2) Not knowing the application, I would say that one way of splitting this out would be

• Alert User When New USB Device Is Inserted (This would show potentially a default icon)
• Alert User When iPhone is attached (This has more specifics around the device, and potentially a different icon/image)
• Alert User When Android is attached (Ditto above)
• Alert User... (Potentially one for each of the supported devices)

Definitely try to avoid splitting across technical lines such as "Front end" and "Back End". It feels right at first due to our technical nature, but demos don't really have the same impact and your PO and Scrum Master won't really have as good of a measure of progress.

3) Task creation is something that your team needs to figure out. If you're running 2 week iterations and the team is not finding task breakdown useful, then I'd say don't do it. If the team feels as if it helps them break down the work necessary to create the story then, by all means, do it. Task creation for the sake of task creation doesn't make a whole lot of sense IMO.

Hope that helps!

Brandon