Skip to main content

Technical US vs Small US

Last post 03:18 pm October 26, 2016 by Timothy Baffa
6 replies
07:54 am October 21, 2016

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?


05:12 pm October 21, 2016

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?


10:17 pm October 21, 2016


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.


10:50 pm October 22, 2016

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.


01:19 pm October 26, 2016

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?



03:17 pm October 26, 2016

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


03:18 pm October 26, 2016

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.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.