Technical stories

Last post 08:46 pm November 27, 2017
by Rolf Dieter Zschau
4 replies
Author
Messages
03:28 pm August 28, 2017

I'm a Scrum Master working with a team which wants to move to just using technical stories, instead of user stories.

They are a component team, working at the UI layer of our stack, building a component which is shared across our product, affecting lots of different users. Our Product Owner agrees with them that user stories don't provide value. I actually think at the UI layer, we are still close to the end user, so user stories for me still make sense.

I feel that this is a symptom of us being a component team - there will be no organisational change any time soon to move towards having feature teams. 

We do use BDD for defining our acceptance criteria, so that at least feels like we will be able to keep defining the behaviour of the system, which feels like its important to keep doing.

I just am not a fan of technical stories - it feels too inward looking and I'm worried that we'll essentially end up with a "do this" and "do that" to do list in our backlog, rather than problems to solve. Has anyone come across a similar situation?

04:59 pm August 28, 2017

Yes.   In my experience, it is a direct result of the component-based, team-specialization model that organizations continue to employ while struggling with Scrum.

 

It is difficult to have a Scrum Team identify with the business-value factor of a PBI when they're so silo-ed in their approach.   Work still looks like a list of to-do's.

 

A couple suggestions that I've had success with that may help your situation:

1)  Any item created on the team's Product Backlog needs to be customer-facing.   This may help with being able to identify with business value/benefit, and may help move the conversation (and story design) away from an assembly-line, horizontally-sliced approach towards more vertically-sliced, broader business-need discussion.

2)  When a story is proposed, some key questions to ask are "Why, What, How, and Who?"   Why is this story being proposed?   What problem is it intending to resolve?   How does this benefit the business?   Who benefits from it?  

 

Very often, the "technical" stories you're experiencing would be tasks on a more business-centric story.

 

A few more questions to ask: Why does the Product Owner feel that user stories don't provide value?   Why does your team feel that Scrum is how they should work?   Why is there organizational resistance to forming feature teams?   What does your team's Definition of Done look like, if they're not being asked to create a cross-functional product increment (per the Scrum Guide)?

 

Good luck!

08:48 pm August 28, 2017

Who will be accountable for the value provided by the component team, i.e. the team which is implementing those so-called "technical stories"?

08:28 am August 29, 2017

They are a component team, working at the UI layer of our stack, building a component which is shared across our product, affecting lots of different users.

Who will be the users of the features provided by the component and why can the PBI not be defined as user stories from the perspective of those users?

09:20 am November 23, 2017

It's a pity that your team and even the PO does not see they are providing value.

I encountered those questions and viewpoints many many times, since I entered the agile community. I was very surprised at first. For me that's a very old and very traditional (and technical) view - I expect to see more modern views in agile communities. For in my past traditional work environment we had a very different notion of "customer" (aka user): A customer of a team is not only the "end user", but could be also internal customers - everyone that uses or is touched by the product . So it's more like the notion "stakeholder" (which is also a wider notion than only sponsor or requirements originator).

I recommend to do a workshop to talk about the notion "customer": Who is the customer of the team? Who is using the product the team is developing? This includes all the other teams using the component. So they are the users and they are looking for business benefit (aka value) in the product (component). Of course the end user is also a customer - and I agree that it's often very hard to formulate the benefit such an end user. So there might be a story that references the end user now and then, but don't stick to that too close or too often - don't let the study book notion of a customer narrow your sight. Look for the customers/users of the component!

The recommended workshop might help the team to start changing their view of the team and their view of providing value. They are not "only component team", but they are providing benefit for their customers! They should be looking for ways to improve such benefit. And this will help to improve the benefit of the overall product for the end user, too.