When to create PBI's from a feature request and where to draw the line into splitting them up?

Question

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?

Answer 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.