Tips for PBI Definition
Generally speaking, if a customer wants a new feature added to the system then the PO needs to break up that new feature into multiple PBIs. What advice do you have for doing this?
For example, if the new feature had a UI, would you recommend that the first PBI be to create the UI and populate it with dummy data? Then the next couple PBI might be to work on some aspect of the backend to provide real data to that prototyped UI.
Posted By Dan Bolton on 06 May 2014 11:55 AM
Generally speaking, if a customer wants a new feature added to the system then the PO needs to break up that new feature into multiple PBIs. What advice do you have for doing this?
For example, if the new feature had a UI, would you recommend that the first PBI be to create the UI and populate it with dummy data? Then the next couple PBI might be to work on some aspect of the backend to provide real data to that prototyped UI.
Hi Dan,
Here an interesting artical by Christiaan Verwijs regarding splitting up PBI's. Especially the first part "Horizontal vs Vertical slicing".
Cheers, Chee-Hong
Hi Dan,
what you describe is an anti-pattern.
The Product Owner should focus on incremental delivery of value, and dummy data does not deliver much value.
Try to find the minimal marketable feature. It should be a slice through all levels: UI, Backend, Database. It is easy to say and difficult to master.
Dan - the example you give is not a releasable feature and hence does not meet the definition of scrum. You need to either refine the PBI further or increase the sprint time to achieve your goal. You may even think of increasing the number of scrum team to achieve this but whatever you do the final outcome should be a releasable product.
the PO needs to break up that new feature into multiple PBIs
The PO does not do this on his own - he along with the Development team will try and break up the new feature into multiple PBIs. This is an on-going process and keeps getting refined as more information is made available or comes to light.
What advice do you have for doing this?
1) Spend at least 10% of the sprint time to refine the PBIs
2) Take dependencies into account (both business and software) to prioritize work
3) Concentrate on the question 'what does the customer want?'
4) Try and frame the PBI into 'As a [role] I would like to [action] so that I can [outcome/result]'
Scrum is an iterative and incremental process - make the most of the flexible approach and keep refining your work.
You should google for "user story splitting patterns". None of them proceed layer by layer
Hims and Ludwig are right. The PO should focus on the incremental release of actual value. When it comes to the elicitation of product backlog items, the whole team should be involved...not just the PO. Mike Cohn blogged about this latter point on Tuesday: http://www.mountaingoatsoftware.com/blog/4-reasons-to-include-developer…
The PO does have the specific responsibility of organizing the Product Backlog so that the formulation of useful and achievable Sprint Goals is facilitated during Sprint Planning.
if the new feature had a UI, would you recommend that the first PBI be to create the UI and populate it with dummy data?
Only if you badly need feedback on that UI.
The other posters have told why the answer to that is generally: "No". But on a few occasions, it might be: "Yes". It depends on where the risk is, where the biggest unknowns are; if you're not at all sure how the UI should work from the user's perspective, or whether your users will want the feature at all, you might want to create the UI first, get feedback on it (from a user panel for example) and iterate on that.
This is a bit on the outskirts of software development with Scrum. If you happen to find yourself in situations like that, I suggest you look into Lean Startup and Eric Ries' book by that title.