How can I provide guidance on technology choices through user stories?

Question

I'm a project manager for a team of firmware engineers making the transition to adopting Scrum and I'm moving to support the team in a Product Owner role. We've just gone through Scrum training and are beginning a month of coaching which is going to be invaluable. Coming from a technical background I can already see the challenge of shifting my point of view from the solution domain to focusing on business value. For me it's very tempting to think of "how" to solve a problem. But I like the concept of user stories and defining vertical slices of functionality that give value to the customer and letting the team determine the "how".

Forgive me if this is a naive question, but as the PO how can I provide guidance on specific technical direction through user stories? My concern is that in some cases without guidance the team may head down the wrong path on key technical decisions.

As a simplistic example I might have a user story:

As a clinician I want the device to record information about the patient's treatment so that I can determine if the patient's therapy has been effective.

Now say time to market is critical and I want to fork out for an off-the-shelf file system stack to save time, what conveys that to the team? They might go off and start writing their own stack from scratch.

Is this sort of guidance provided through:

1. Conversations during sprint planning and backlog grooming? But if so, is it my place as the PO to even be suggesting how to solve a problem.
2. Acceptance criteria? I don't really like this, I have a bad feeling about making acceptance criteria so prescriptive that they specify how to solve a problem.
3. Constraints?

Thanks in advance. I could (and will) ask our Scrum coach but I won't be able to do that before Monday and this question has been really bugging me :)

Answer 1

Is there an architect/tech lead which is part of the team that you can talk to?

Ultimately, I think technical ownership lies w/ the delivery team. As the PO, you can provide direction through your acceptance criteria, but rather than formulating your AC around the "how", talk about the "why" and what problems your hypothetical stack would solve (perhaps there are alternatives that also fulfill your AC).

You can always suggest technical direction to the team, but I would be careful and allow the team to choose what works best for them (this includes the architect/tech lead). If there are technical concerns, I would put those into your acceptance criteria. A key principle of Agile / Scrum is that teams work best when empowered and given the authority to make decision that affect them. I definitely recognize the need to guide direction (especially if you think the team is making a wrong long-term technical choice), but there is the trade off if the team disagrees and a resistance forms. If the team agrees, great-- just keep in mind the boundaries of the PO role and be careful of the "exception to the rule" becoming an "expectation".

Also, talk to your Scrum Master, he/she should be a resource for this sort of stuff.

Hope this helps, I kind of jotted this down quickly.

Answer 2

My experience has been to have a technical lead who provides this direction through conversations and/or technical documentation (so No. 1 on your list). This person will also be able to give the technical guidance needed for key decisions. They will be able to recommend/monitor/reinforce best practices. This is usually not the PO(Product Owner) as it requires having a different point of view.

I don't like the acceptance criteria/constraints approach being too formal (which also takes time and energy). The whole point of Agile of course is not to be focusing on creating formal procedures but delivering stories and getting the code written for that.

Answer 3

You can't guide technology choices through user stories; they are deliberately agnostic on technology decisions. That's kind of the point--they speak only to functionality, not implementation.

Technology decisions should be made based on what the team already knows, what they want to know, what expertise is available, what's already in place, what interfaces with existing systems the easiest, etc.

Whoever is in charge of development should be guiding this, taking input from anybody that knows anything.

Answer 4

Welcome to the world of Scrum. You are right in guessing that providing technical input in the user story might be wrong. Here's why. The User Story is about the user. The user does not care about the technical information. You would not care about the technical information had you come from a less technical background. What you, as the PO would care about is that the team delivers the value you are asking for. Any way they can (this often means that they should be encouraged to think out of the box and look for a simple solution).

If, however there are certain criteria that the solution must meet for the story to be considered successful, you will of course provide them in the acceptance criteria (often written on the back of the story card, in the GWT form). For example, perhaps you need the service to run in under 2 seconds, or due to customer requirements, such as interfacing with another system, your service must provide an XML-based result.

Other technical opinions (which might be biased, like by your skill-set) should be kept unofficial. Remember that user stories are not contracts, but rather a promise to have a conversation! During the sprint you, the PO, are considered a "chicken", therefore your advice should considered, but it should be ultimately up to the team to own the delivery of the solution.

I hope this helps, and you find the transition from command and control to agile as easy as possible. It's one heck of a ride, but well worth it.

Answer 5

You need to let go!

Its not your job any more. You need to trust the technical guys to make the right decisions, and, concentrate on getting the Product right from the marketing business point of view.

After all you would have hated it if the product owner had questioned your judgement when you were head of the technical team. By concentrating on your "last job" you will perform poorly in your new job. Being the "Product Owner" does not sound that easy, and will require you to master a new set of skills and looks a big enough of a challenge without the distraction of doing someone else's job as well.

Answer 6

Don't suggest how to solve the problem, but DO communicate what are the driving business motivations for the story.

IMHO, a key responsibility of a PO is to effectively communicate the business and market context to the team so that they can make valid, informed decisions.

In this case, time to market is critical, so communicate that to the team: "This story is very important for business that we want to get out really soon, so consider if we can just use some off the shelf solution or third party library."

Then leave it to the team to make the decision. They might find that writing their own is really faster, or maybe integrating a third party solution is faster, so let them investigate and decide.

A good team can change their implementation strategy to align with the business need. But, they may not understand that business need. As a PO you need to bridge that gap.

Answer 7

One of agile tenets is Empower people and that is what you must follow if you want to go with Scrum. In other words Scrum / Agile is not for teams where team members are not able to take responsibility for their decisions => you should have some skilled / experienced team members to take care of your technical details.

As PO you can make constrains (lets call them global acceptance criteria or non functional requirements) and some of them can be technical. For example if your company has a strategy to have every application in Java you can make such a constraint at the beginning of the project but you cannot drive design / architecture of every single user story - it is team responsibility. Such global constraints should be defined upfront because they affect estimation of every user story.