Value Team

Information Technology practitioners have made great strides improving delivery using Agile concepts. Development Teams are now faster, more empowered, and motivated using frameworks like Scrum. A key to this success is that delivery teams work closely with the business through their proxy, the Product Owner. In my work performing Agile consulting and strategy, however, I consistently hear delivery and performance concerns regarding the critical role the Product Owner must play, including:

What happens when the Product Owner cannot keep up?

How do Product Owners gather information and opinions from a wide group of people across the business and keep up with the speed of their Development Team?
What do you do if the project requires more information than any one Product Owner can respond to?

The key to solving the concerns listed above is in the creation of a Value Team. A Value Team is a group of representatives (stakeholders) who help the Product Owner make decisions about the value of features and functionality for each product. The Value Team is responsible for:

Prioritizing business needs; Answering questions about desired functionality; Creating new stories as necessary; and Deciding when the project is complete.

An effective Value Team is critical for any successful product implementation. In the same way that Development Teams have Scrum, Value Teams have their own framework to identify, organize, and prioritize new system functionality. This article discusses how Value Teams are assembled, what their operating framework should look like, and what they should deliver.

Assembling the Team

The Value Team is identified by the Product Owner. Team members are chosen either as representatives for their business unit or for their expertise in a particular subject relevant to the project. As with Agile Development Teams, a Value Team should have between 5 and 9 people. If the scope of your project requires more than 9 people, then you will need to organize multiple Value Teams.

As you select your team “begin with the end in mind.” Ask yourself if the people you select will be engaged in the project, will have enough credibility to champion the solution, and will have enough information to answer questions.

Operating Framework

The Value Team needs their own operating framework that is synchronized with the processes of the Development Team. To keep things simple, lets discuss the Value Team’s meetings when working with a Scrum team. The image below shows how the teams work together.

Value Teams

The Sprint Plan Review occurs after the Sprint Planning meeting. The Product Owner shares the results of the Sprint Planning meeting so that the Value Team knows what is being worked on. If there are any questions that arose in the Sprint Planning Meeting, they can be addressed during this meeting.

The Daily Scrum is separate from the one held by the Development Team. During the Scrum the Product Owner shares what he/she is working on in the normal fashion (yesterday I…, today I plan to…). If the Product Owner has any questions he can pose them directly to his team.

Backlog Prioritisation occurs just after the midpoint of the sprint. In a two week sprint it will happen at the start of the second week. The Value Team reviews the backlog items and clarifies and prioritizes the order in which things should be done. This is done well in advance of Sprint Planning so that the Planning process is quick.

After the Sprint Review the Product Owner holds a Product Owner Review. The Product Owner shares the results of the most recent sprint and demos features of the application if possible. The Value Team reviews their understanding of the product and discusses what they learned.

Finally, the Value Team has their own Sprint Retrospective. The retrospective is for the business team, but functions the same way as the Development Team’s sprint.

A well organised Value Team following the framework levels the playing field so that the business can keep up with the Agile Development Team.