Separating What from How - Design in an Agile Environment

Question

In an agile (scrum) environment, how do you get product management to create small enough backlog items or stories without having them do all the design, which is not their specialty? In other words, how do you separate the what (business requirements) from the how (design) in agile development?

Answer 1

With scrum, the product management should be one person: the product owner .

What you want to do is done during the sprint planning, where the whole team (product owner, scrummaster, developers) should be present.

The what should be defined as user stories by the product owner . The user stories are supposed to be high level, limiting your product owner to express the business requirements in one sentence stories should do the trick.

e.g. As a StackOverflow user, I would like to see my reputation

One of the goal of the sprint planning is to decide the stories that should be done during the sprint. So when the stories are chosen by the product owner, the team can subdivide them, talk briefly about the design (the how) and estimate them.

In a nutshell, the what should be done by the product owner, the how by the team. If this process is clearly explained to the product owner, he won't try to design everything. If he tries anyway, the scrummaster will stop him.

Answer 2

Don't forget that the product backlog items should be rated in order of importance, using a weighting system (prime numbers, fibonacci,..), so that if you have items in your backlog that of similar importance (i.e. 2 items with a weight of 21), then they should in theory both try and be inserted in the sprint ahead of the 13s and 8s.

Answer 3

The first thing you must do, and that is the cause of a great number of Scrum Projects failures, is to teach your product management to play the Product Owner role. You have to show him that he is responsible for the ROI of the project, and for that, he is responsible for prioritizing the stories/itens/business needs/features or whatever you are using to compose your Product backlog in a manner that the most valuable itens are with higher priorities.

I'm in favor of using user stories as product backlog itens and then, at the sprint planning, breaking on smaller tasks the stories selected to compose the sprint backlog.

What you should always have in mind when writting, or helping your PO to write, your user stories is that the stories should be INVEST. Independent, Negotiable, Valuable to customers, Estimatable, Small and Testable.

I think at the beginning using the template bellow might be helpful to keep the PO focused on the business goals:

"As a - type of user -, I want -some goal- so that -some reason-."

One story example would be "As a stackoverflow user, I want to vote on an answer so that the most valuable answer can easily be finded."

Don't forget to make the PO write or define the acceptance Test for each story of your Sprint Backlog as it can be use as a basic criteria to determine if a story is fully implemented.

To the example above, two possible acceptance test are:

"Test to vote up a answer"

"Test to Vote Down a answer"

With this story and two acceptance test the team knows that the stackoverflow user can vote on the answers and to the story status be updated do Done, it is necessary that the system allow the user to vote up and down an answer without throwing exceptions.

Answer 4

During the backlog (re)estimation (after prioritisation) the Team should be doing Modelling in order to understand the full extent of the User Story and be able to accurately estimate the complexity. This isn't the full extent of the modelling which may take place (teams may do more doing development), but it is a great place to start and will be able to take advantage of the Customer/Product Owner being around to answer questions there and then.

As a result of this, the resulting discussion will help you work with the Product Owner to split their requirements down to a meaningful and suitable granularity.