How to use the Product Backlog to increase communication and become productive early on in the project.

As a Scrum Coach I sometimes come across projects that simply aren’t working out. Most of those have a problem with the communication between the Product Owner and the Team. Here I present an approach based on the intellect of Dan North.

As I see it, the Product Backlog is not only a list of functionality and issues. It can also be put into service to increase the developer team’s domain knowledge, commitment and collaboration as well. On several occasions, I have been successful in improving the communication between the Product Owner and the Team by using the Product Backlog as the interface through which communication takes place. By shifting some of the Product Owner’s responsibilities to the Team, I have managed to get them involved in the evolution of the requirements.

Epics – Stories – Scenarios

Evolutionary requirements isn’t just a way to minimize the amount of changing requirements and amount of time spent before development starts. It is also a great way to build a bridge from the Product Owner and his problem domain to the Team and the solution domain.
I find it useful to think in terms of Epics-Stories-Scenarios and use the Team to help the Product Owner evolve the requirements along those lines to build the bridge. To get the Team into the habit of working with the Product Owner and the requirements, I introduce the responsibilities of Business Analyst and Quality Assurance to the team, one person per responsibility, and I rotate them each Sprint.

Rotating responsibilities
Introducing the Business Analyst and Quality Assurance and advocating the shared responsibility for the Product Backlog removes uncertainty about what’s expected of everyone involved as well as strengthening the collaborative climate of the project. Rotating the responsibilities provides the team with a natural way of sharing knowledge and increasing the overall competence of the team members. All of this builds trust and confidence – important factors in getting self-organization and commitment up and running.
Some may argue that the introduction of Business Analyst and Quality Assurance goes against the no-role policy of Scrum, but as far as I am concerned it is about delivering working Software and whatever gets you there is good practice. Don’t forget that Scrum is about continuous improvement rather than process roll-out, and the most important thing is to get it right the final time!

The job of a Business Analyst The Business Analyst starts his job in Sprint Zero, i.e. the Sprint preceding the first development Sprint. He collaborates with the Product Owner to:
♣ get the overall business goals of the project in place
♥ establish the level of detail for the requirements and how they should be communicated to the Team (definition of “done” for a story, to put it simply).

It is important not to do too much of it, since the level of detail will shift as the team and Product owner get to know each other and their understanding of the problem and solution domain increases.
The overall business goals are the problems the projects are supposed to solve and are expressed in terms of epics:

As a [stakeholder] I want [feature] so that [benefit].

For each Epic the Stakeholders should be identified to enable the Team to involve actual people when it comes to breaking the Epics down into Stories or understanding the problem at hand. The more involved the team is in this process, the better they will understand the business and the better they will become at making informed decisions.
♣ Keep the Epics on cards in big black letters and stick them on a wall to make them visible to everyone. If you run out of wall it probably means that there are too many Epics.
♦ At the same time this is being done, the Team should start considering the technical solutions available and start creating the overall architecture in the form of simple models – stick those models on the wall as well to keep them visible and usable for sprint planning and daily discussions.
♠ This is also the time for the Team to start asking questions along the lines of ‘what does it actually mean to …’ and ‘how is it done at the moment and why isn’t that good enough’ as well as questions regarding the potential users: ‘who are they’ and ‘how can we make it easy for them’. Asking these kinds of questions helps identify the incidental stakeholders, the owners of the non-functional requirements who come into the picture as a result of the implementation decisions made – anyone affected in some way by the results of the Team’s work. and refined together with the Product Owner, and communicates them to the Team at estimation. When development of a Story is done, Quality Assurance is responsible for verifying that all Scenarios are fulfilled and that the agreement with the Product Owner is honored. If automatic acceptance tests are used, it is Quality Assurance together with a developer that makes sure tests are written for each Scenario and that the tests are in good shape. Having the entire Story in place, you are finally ready to do some estimation. I normally let the team do estimation before the Scenarios are written, simply because I don’t want too much effort going in to the requirements before being sure they will actually be developed and to give the Product Owner some sense of cost to enable planning. This of course means that the estimates might change when the scenarios come into play. In that case you would have to re-estimate or remove some Scenarios to stay within the estimate. The removed Scenarios should be estimated and kept in the Product Backlog to ensure that nothing is lost.. The next step is to drive out the initial Story List and get some more knowledge into the team. The Product Owner prioritizes the Epics and the Business Analyst starts dealing with the top two or three. This means getting some more detail in the form of User Stories, the As a [stakeholder] I want [feature] so that [benefit] format applies here as well as the cards – at least before there are too many. Eventually it always becomes a problem having them on cards, but it is a simple solution that makes it easy to sort, group and prioritize the stories in a collaborative fashion, and that is what is needed at the beginning of a project.

The job of Quality Assurance

Before a story can get into a Sprint Planning, it needs to be estimated and before it can be estimated, the Team needs to understand it and have a clear understanding of when they are done with it – this is where the Scenarios and Quality Assurance come in.

While the Business Analyst works with the Product Owner and the Team to get Epics and Stories in place, the Quality Assurance is responsible for the next evolutionary step – the Scenario. A Scenario takes the form of given [some context] when [I do something] then [this happens], if it is a more complex scenario you could add when [I do another thing] then [this new thing happens] as many times as appropriate. Scenarios are written on the back of the Story cards. If there’s not enough room, chances are there are too many Scenarios and splitting the Story should be considered. Quality Assurance works with the Business Analyst to find Scenarios, gets them verified and refined together with the Product Owner, and communicates them to the Team at estimation.
When development of a Story is done, Quality Assurance is responsible for verifying that all Scenarios are fulfilled and that the agreement with the Product Owner is honored. If automatic acceptance tests are used, it is Quality Assurance together with a developer that makes sure tests are written for each Scenario and that the tests are in good shape.
Having the entire Story in place, you are finally ready to do some estimation. I normally let the team do estimation before the Scenarios are written, simply because I don’t want too much effort going in to the requirements before being sure they will actually be developed and to give the Product Owner some sense of cost to enable planning. This of course means that the estimates might change when the scenarios come into play. In that case you would have to re-estimate or remove some Scenarios to stay within the estimate. The removed Scenarios should be estimated and kept in the Product Backlog to ensure that nothing is lost.