Technical US vs Small US
Hey,
I would like to know how are you fighting with dilema technical US vs small US. Here is the case:
- to provide new functionality working we need to deliver 1, 2, 3;
- I can either have 1, 2, 3 in one US, but it will be huge US (like let's say 34SP);
- Or I can have three US's (each 8SP), but only the third one is delivering real value for business user (first two are related to 'technical staff' needed for the third one);
So there is a conflict between Small and Valuable (from INVEST).
How are you addresing this issue?
What does the Product Owner think about this potential backlog item, and how it might be broken down to deliver value earlier? Does he or she consider technical staff to be stakeholders in the product? If not, why not?
The US that is estimated 30-40 SP is too big (from my experience the max is 8-10 SP). Discuss with PO how to present this big US with smaller backlog items that are acceptance testable and have a stakeholder's value.
SP are a relative abstract measure so I don't know how large are those PBIs. Which is the team velocity? What about the possibility of split vertically the 34SPs in a different way? Focusing on deliver less value which requires less technical stuff.
Thanks for replay.
@Ian Mitchell: it is always hard to explain to PO technical US. So PO is prefering to have big US, which will deliver business value.
@Sergiy Pshenychnyy, @Luis Javier Peris Morillo: It doesn't matter wheter it is 34SP or different value. As you noticed - SP is a relative measure. It was only the case of having one big US or three smallers (like each about 30% of big one).
Let's talk about real-life example. We have front-end, which is build as drag&drop.
Business functionality/value - I want to have possibility to configure some fields on the screen as obligatory.
To deliver this functionality I need to:
1. Extend some class - adding 'obligatory' parameter.
2. Use this parameter in front-end and configure front-end behaviour.
3. Create UI for configuration of 'obligatory' parameter.
4. Configure warnings and communicates on front-end side.
All 4 points are necessary to have real business value. This is our big_US. But also I can create small_US's for:
1-2: we have possiblity to configure obligatory by inserts into database using SQL. There is some value in it. But it can be hard to explain it to business users.
3: we do not need using SQL, cause we have UI for it. In this moment business users are able to see value, but...
4: better user experiance. And here business users are really happy from the funcionality.
What is your apporach? Having one US or three US's?
> it is always hard to explain to PO technical US. So PO
> is prefering to have big US, which will deliver business value.
Might that be the problem which needs to be solved?
If the "technical staff" you referred to earlier are stakeholders in the product, and if the stories which interest them affect product value, then the PO must understand and represent those interests. What would the consequences be for the product if these stories are not implemented?
A PO must be able to articulate all stakeholder needs, and thereby maximize product value through a well structured and ordered Product Backlog. He or she is not merely a business representative.
All 4 points are necessary to have real business value.
Keep in mind, there are many benefits around slicing stories and making them smaller. They are easier to estimate, create better work flow, and provide quicker feedback (in my opinion, the greatest benefit!).
Don't get hung up on the "batch" view of work, where functionality simply doesn't make sense until it is all built and working.
Ask yourself "What is the smallest thing that we can build, that will provide us with the quickest feedback on either confirming or adjusting our direction/priority?" Use this question as a basis for everything you build under whatever Agile framework you're using, and you'll be in good shape.