Agile software development in practice – Product backlog items

Some time ago I was working in a team of business analysts that were helping the product owner of a large consumer website to define product backlog items and make them ready to be implemented by the development teams. The product backlog items we defined were in the form of user stories: sentences in the form “As a … I want to … in order to …”. The product we were working on was very big and there were a lot of stakeholders involved. At one point one of the stakeholders came up with a user story that would require a change to the customer login functionality of the website, so I wanted to know what the impact would be of this on the existing system and if it wouldn’t interfere with any of the other user stories. Unfortunately, the only documentation of the system was the list of implemented user stories and there was no way to see any interdependencies. The only way to go for me was to read all the user stories and still that didn’t give a complete picture of the system. I had the feeling that there must be another way. I could have bought some books to learn what experts had written on this subject. But I was more interested in how it really works in practice. So I started asking other teams, product owners and project managers how they build their backlogs and managed interdependencies on it. I’ve found that each team works in their own way, depending on the specific circumstances, but there are some similarities that come back everywhere.

When a completely new system is going to be build or an old system is going to be rebuild completely there is a phase in which the scope of the system is defined and from this product backlog items emerge. In most cases this happens in workshops in which business analysts, end users, testers and other stakeholders participate. Usually developers are not yet involved in this phase. The product backlog items together describe the system to be build and can be translated one on one to (smart) use cases, data flows or any other artifact representing a piece of functionality. One or two sprints before a product backlog item is taken into sprint some more detail is added to the product backlog item, usually by writing functional documentation on a high level, leaving out details that can be added later. When the product backlog item is taken into sprint, the whole development team looks at it together with the stakeholders, filling in details and finding the best solution together. During sprint, the item is build and tested and the documentation is written in parallel. Interdependencies between the backlog items can be seen using models. See below for an example of a use case model, in which it is visible that the use cases “Select process” and “View total day production” have dependencies with both the use cases “Approve registered production” and “Register day production per employee”.

When a system in use is developed further, product backlog items are continuously being added to the product backlog by the product owner. Input for this usually comes from sprint demos or from workshops with stakeholders. In this case the product backlog items can be new functionality to be added to the system, changes to existing functionality, performance improvements and bug fixes. The items usually require changes to one or more existing pieces of functionality. In that case, before the item is taken into sprint the impact on existing functionality should be known and the documentation adjusted during sprint. If for every backlog item it is known what parts of the system it impacts it is easier to find interdependencies.

To conclude: I have found that in cases were visual models were used interdependencies were more easily found. Also, having some level of system documentation that represents the current state of the system is necessary to be able to make changes to an existing system. A good basis for this documentation are (smart) use case models. But documentation and models are not enough, still a person or team that knows and understands the complete system is needed to develop high quality software (individuals and interactions over processes and tools). Concerning the team I worked in: I think there were quite some things I could do to make my life and that of my team members easier by introducing some visual models. Unfortunately, I could not stay around to make these improvements due to pregnancy, but I did use my findings in my later projects and will continue to do so.

Related Posts


On the ground with Agile

Singhania, Sunil
July 18, 2018
At Capgemini, we can meaningfully offer to start Agile onshore, then graduate to nearshore and offshore as clients’ confidence in the process grows.

The European solar industry readies for the digitalization challenge

Marianne Boust
January 11, 2018
“Solar is now cost-competitive against other sources of power generation”—World Energy Markets Observatory, 2017

Agile means profitable

Herbert Goertz
December 1, 2017
A Capgemini ad asks the question: “What good is an ERP solution if it doesn’t increase profitability?” The answer is: “Not very good, and also not very agile.”

By continuing to navigate on this website, you accept the use of cookies.

For more information and to change the setting of cookies on your computer, please read our Privacy Policy.


Close cookie information