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.

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

Leave a Comment

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