Skip to main content

How to make an BPI independent

Last post 04:34 pm May 6, 2015 by Charlie Barkley
6 replies
10:58 am May 4, 2015

Hey folks!

I learned that a BPI should be independend from other things. Actually I'm planning a game development project.
Therefore I already gathered some BPI in the Backlog Meeting. (Picture Link)

In the link above you can see several of them.

I pick out one: "User presses up arrow to make character jump"
This actually nice but it depends of some architectical things like the control system being implemented first.
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.

Should I define another "User Group" ?
Like "The Developer can implement controls to the game to create interaction"
or "The Developer is able to implement controls into the game engine".

I hope you get my point?

Thanks for your help in advance.


11:34 am May 4, 2015

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.

11:48 am May 4, 2015

well 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?

09:46 am May 5, 2015

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.


10:14 am May 5, 2015

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

10:43 am May 6, 2015

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

04:34 pm May 6, 2015

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

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

Please note that the first and last name from your 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. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, 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 may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.