Capping IT Off

Capping IT Off

Opinions expressed on this blog reflect the writer’s views and not the position of the Capgemini Group

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.

About the author

Marieke Bode
Marieke Bode
I help my clients to create high value software by making them succeed in agile software development.
3 Comments Leave a comment
Thank you very much for the great article. I am waiting for more new ideas from you. Keep it up.
Nice article. For the complete overview of a software system you could write a Software Architecture Document. Though it would not have the level of detail as your use case, it would help to keep an overview of the system.
mabode's picture
Thanks for the tip. Yes, I've seen projects that used Software Architecture Documents. Some added more value than other. I think a SAD that uses models to represent the system (a use case model being one way to represent it) adds most value.

Leave a comment

Your email address will not be published. Required fields are marked *.