How to make an BPI independent

Hi Charlie, it looks to me like your PBI's are not only the what and why but also the how. Instead of saying "press up to make the character jump". What about saying "the character must be able to jump" and let the team come up with the best way to solve that problem.

well scrummethodology.com taught me WHO, WHAT, WHY so I kept that pattern.

So you say PBI should be simple WHAT/WHY and the Scrum Meeting where Tasks are being declared should be the place where the team approaches the best way to solve a problem?

That leads to one concern in my head.

"The Character must be able to walk" - Team discusses and says "We need to implement a control system"
next PBI:
"The Character must be able to jump" - Team discusses and says again "We need to implement a control system"

You know what I mean? I would like to keep out cloned Tasks anyhow :/ is this possible anyhow?

Hello Charlie,

It's a good question.

Really you can not always get all the PBIs to be independent. The starting point is that both the development team and the product owner know that dependency. One way to remove that dependency is to unify the PBIs which have a common dependence on a single PBI. If the resulting PBI entails an acceptable effort that can be done in a Sprint, it could be your solution. If, however, it is not acceptable in a single Sprint, is there a completely logical order to be followed? If for example, the character must jump before any other action (move or jump), you have no problem in assuming that the work will be done in that PBI and the rest of PBIs will be made later. If that is not the case you can create a more generic user story and series of specific User Stories, for example:

Move the character. As a gamer, I can use a key, so that I'm able to move.

Jump. As a gamer, I can use arrow up, so you can jump.

Change direction. As a gamer, I can use a key, so I can move in another direction.


Thus, all tasks and the weight will fall on the first User Story without really indicate what action (moving or jumping) is being estimated.

Regards.

> Now how can I get these independend? It's a user story and a
> user won't have anything to do with the architecture of a game.

What matters is that at least some business value is delivered each and every Sprint. In other words, it's fine to concentrate on getting an architecture in place as long as something of use to stakeholders is made available in a potentially releasable increment. This could just be one or two user stories which early adopters can then evaluate.

A sensible approach would be to choose stories which exercise as much as possible of the architectural foundations being developed. Sometimes these stories are referred to as "tracer bullets" as they are fired through an emergent architecture and thereby validate as much of it as possible in a timely manner.

We tend to assume that we have to come up with the perfect architecture right away. Your example: "We need to implement a control system." Sounds to me like its about THE control system.

In our case, we try to start with only as much architecture as is necessary to implement the first features while avoiding obvious dead-ends. We take it from there and remind ourselves to accept rework. As Ian says above, the first features will prove if we are on the right track. If not, it is okay to take a different approach.

So in your example, I would formulate it like "we need a control system that allows the first feature(s) and seems like a reasonable approach, knowing that more features will come."

Alright guys thanks for the advices!

I think I can get along with the fact that the task which would define the "implement control system" could also be called "implement control systematics to jump" & "implement control systematics to walk".