New Articles

Three Tips to Break the Ice between Your Software Development Team and Product Backlog


Three Tips to Break the Ice between Your Software Development Team and Product Backlog

Helping agile teams to improve, I often saw one problem, especially with the teams recently migrated from old-school methods, such as RUP. In these teams, product owners are the only team members proactively involved in backlog management. Such a situation contradicts the Scrum ideology and dramatically decreases team performance. However, just a few simple steps would help to break the ice and improve the situation substantially in weeks.

During the last few months, I prepared four separate articles describing how good old requirements management methods may improve your backlog-fu. Now I want to demonstrate how these methods may help to engage your development team into backlog management.

First of all, you don’t want to force them into the backlog. It is against the whole idea of people management in Scrum. Instead, let’s see how you can create an environment where the development team becomes engaged in this job. Or, in other words, let’s facilitate their engagement.

Tip number one. Make sure that your development team can understand the stakeholders.

Developers are skilled in communication with computers, not other people. Do your homework on learning your stakeholders and their language and share this information with the development team. In other words, establish the common language and the frame of reference!

Read more about learning the stakeholders:

Tip number two. Help your development team sympathize with the client.

If you help the development team feel the pain that stakeholders suffer, the boring day-by-day routine will turn into the mission to relieve the pain and solve the problem. This feeling motivates the development team to understand the business values and outcomes and apply their efforts to do the job in the best possible way.

Read more on how to start with the problem analysis: 

Tip number three. Let the development team apply their knowledge and experience in the areas where they are better than you are.

The requirements are something more than just the “list of stories.” Sure, telling “what the system should do” is your primary responsibility, you are trained to do it, but there are a lot more. All these scary words, such as usability, reliability, and supportability, are as important as functionality is. And your team knows better about these things than you do and often than the customer does. After all, this is their “bread and butter.”

Let the developers understand that their opinion matters. Ask the developers the proper questions. Use URPS from FURPS and development-related attributes from the five-attribute model as a template for your questions.

That would magically turn a scary and odd job of “backlog management” into knowledge sharing and expertise application within clear and well-structured patterns. And I rarely see developers who hesitate to demonstrate their competence in these conditions.