{"id":235,"date":"2010-12-06T12:55:48","date_gmt":"2010-12-06T11:55:48","guid":{"rendered":"http:\/\/leanmagazine.net\/?p=235"},"modified":"2024-03-15T15:18:50","modified_gmt":"2024-03-15T14:18:50","slug":"dealing-with-the-product-backlog","status":"publish","type":"post","link":"http:\/\/leanmagazine.net\/uncategorized\/dealing-with-the-product-backlog\/","title":{"rendered":"Dealing with the product backlog"},"content":{"rendered":"

\"\"<\/h4>\n

How to use the Product Backlog to increase communication and become productive early on in the project.<\/strong><\/h4>\n

As a Scrum Coach I sometimes come across projects that simply aren\u2019t 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.<\/p>\n

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\u2019s 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\u2019s responsibilities to the Team, I have managed to get them involved in the evolution of the requirements.<\/p>\n

Epics \u2013 Stories \u2013 Scenarios
\n<\/strong><\/h4>\n

Evolutionary requirements isn\u2019t 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.
\nI 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.
\n
\nRotating responsibilities <\/strong>
\nIntroducing the Business Analyst and Quality Assurance and advocating the shared responsibility for the Product Backlog removes uncertainty about what\u2019s 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 \u2013 important factors in getting self-organization and commitment up and running.
\nSome 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\u2019t 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!<\/p>\n

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:
\n\u2663 get the overall business goals of the project in place
\n\u2665 establish the level of detail for the requirements and how they should be communicated to the Team (definition of \u201cdone\u201d for a story, to put it simply).<\/p>\n

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.
\nThe overall business goals are the problems the projects are supposed to solve and are expressed in terms of epics:<\/p>\n

As a [stakeholder] I want [feature] so that [benefit]<\/em>.<\/p>\n

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.
\n\u2663 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.
\n\u2666 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 \u2013 stick those models on the wall as well to keep them visible and usable for sprint planning and daily discussions.
\n\u2660 This is also the time for the Team to start asking questions along the lines of \u2018what does it actually mean to \u2026\u2019 and \u2018how is it done at the moment and why isn\u2019t that good enough\u2019 as well as questions regarding the potential users: \u2018who are they\u2019 and \u2018how can we make it easy for them\u2019. 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 \u2013 anyone affected in some way by the results of the Team\u2019s 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\u2019t 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]<\/em> format applies here as well as the cards \u2013 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.<\/p>\n

The job of Quality Assurance<\/strong><\/p>\n

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 \u2013 this is where the Scenarios and Quality Assurance come in.<\/p>\n

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 \u2013 the Scenario. A Scenario takes the form of given [some context] when [I do something] then [this happens]<\/em>, if it is a more complex scenario you could add when [I do another thing] then [this new thing happens]<\/em> as many times as appropriate. Scenarios are written on the back of the Story cards. If there\u2019s 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.
\nWhen 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.
\nHaving 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\u2019t 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.<\/p>\n

The job of a
\nBusiness
\nAnalyst
\nThe Business Analyst starts his job in
\nSprint Zero, i.e. the Sprint preceding
\nthe first development Sprint. He collaborates
\nwith the Product Owner to
\n\u2663 get the overall business goals of the
\nproject in place
\n\u2665 establish the level of detail for the
\nrequirements and how they should
\nbe communicated to the Team (definition
\nof \u201cdone\u201d for a story, to put
\nit simply).
\nIt is important not to do too much
\nof it, since the level of detail will shift
\nas the team and Product owner get
\nto know each other and their understanding
\nof the problem and solution
\ndomain increases.
\nThe overall business goals are the
\nproblems the projects are supposed to
\nsolve and are expressed in terms of epics:
\nAs a [stakeholder] I want [feature] so
\nthat [benefit].
\nFor each Epic the Stakeholders
\nshould be identified to enable the
\nTeam to involve actual people when
\nit comes to breaking the Epics down
\ninto Stories or understanding the
\nproblem at hand. The more involved
\nthe team is in this process, the better
\nthey will understand the business and
\nthe better they will become at making
\ninformed decisions.
\n\u2663 Keep the Epics on cards in big black
\nletters and stick them on a wall
\nto make them visible to everyone.
\nIf you run out of wall it probably
\nmeans that there are too many Epics.
\n\u2666 At the same time this is being done,
\nthe Team should start considering the
\ntechnical solutions available and start
\ncreating the overall architecture in the
\nform of simple models \u2013 stick those
\nmodels on the wall as well to keep
\nthem visible and usable for sprint
\nplanning and daily discussions.
\n\u2660 This is also the time for the Team to
\nstart asking questions along the lines
\nof \u2018what does it actually mean to \u2026\u2019
\nand \u2018how is it done at the moment
\nand why isn\u2019t that good enough\u2019 as
\nwell as questions regarding the potential
\nusers: \u2018who are they\u2019 and \u2018how
\ncan we make it easy for them\u2019. Asking
\nthese kinds of questions helps identify
\nthe incidental stakeholders, the
\nowners of the non-functional requirements
\nwho come into the picture as
\na result of the implementation decisions
\nmade \u2013 anyone affected in some
\nway by the results of the Team\u2019s work.
\nand refined together with the Product
\nOwner, and communicates them to the
\nTeam at estimation.
\nWhen development of a Story is
\ndone, Quality Assurance is responsible
\nfor verifying that all Scenarios
\nare fulfilled and that the agreement
\nwith the Product Owner is honored.
\nIf automatic acceptance tests are used,
\nit is Quality Assurance together with
\na developer that makes sure tests are
\nwritten for each Scenario and that the
\ntests are in good shape.
\nHaving the entire Story in place, you
\nare finally ready to do some estimation.
\nI normally let the team do estimation
\nbefore the Scenarios are written, simply
\nbecause I don\u2019t want too much effort
\ngoing in to the requirements before
\nbeing sure they will actually be developed
\nand to give the Product Owner
\nsome sense of cost to enable
\nplanning. This of course
\nmeans that the estimates
\nmight change when the scenarios
\ncome into play. In
\nthat case you would have to
\nre-estimate or remove some
\nScenarios to stay within
\nthe estimate. The removed
\nScenarios should be estimated
\nand kept in the
\nProduct Backlog to
\nensure that nothing is
\nlost..
\nThe next step is to drive out the initial
\nStory List and get some more knowledge
\ninto the team. The Product Owner
\nprioritizes the Epics and the Business
\nAnalyst starts dealing with the top two
\nor three. This means getting some more
\ndetail in the form of User Stories, the
\nAs a [stakeholder] I want [feature] so that
\n[benefit] format applies here as well as
\nthe cards \u2013 at least before there are too
\nmany. Eventually it always becomes a
\nproblem having them on cards, but it is
\na simple solution that makes it easy to
\nsort, group and prioritize the stories in
\na collaborative fashion, and that is what
\nis needed at the beginning of a project.
\nThe job of
\nQuality
\nAssurance
\nBefore a story can get into a Sprint
\nPlanning, it needs to be estimated and
\nbefore it can be estimated, the Team
\nneeds to understand it and have a clear
\nunderstanding of when they are done
\nwith it \u2013 this is where the Scenarios
\nand Quality Assurance come in.
\nWhile the Business Analyst works
\nwith the Product Owner and the Team
\nto get Epics and Stories in place, the
\nQuality Assurance is responsible for the
\nnext evolutionary step \u2013 the Scenario. A
\nScenario takes the form of given [some
\ncontext] when [I do something] then [this
\nhappens], if it is a more complex scenario
\nyou could add when [I do another thing]
\nthen [this new thing happens] as many
\ntimes as appropriate. Scenarios are written
\non the back of the Story cards. If
\nthere\u2019s not enough room, chances
\nare there are too many Scenarios
\nand splitting the Story should
\nbe considered. Quality Assurance
\nworks with the Business Analyst
\nto find Scenarios, gets them verified<\/div>\n","protected":false},"excerpt":{"rendered":"

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\u2019t working out. Most of those have a problem with the communication between the Product Owner and the Team. Here I present […]<\/p>\n","protected":false},"author":32,"featured_media":320,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[22,83,14,1],"tags":[15,26,6,25],"_links":{"self":[{"href":"http:\/\/leanmagazine.net\/wp-json\/wp\/v2\/posts\/235"}],"collection":[{"href":"http:\/\/leanmagazine.net\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/leanmagazine.net\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/leanmagazine.net\/wp-json\/wp\/v2\/users\/32"}],"replies":[{"embeddable":true,"href":"http:\/\/leanmagazine.net\/wp-json\/wp\/v2\/comments?post=235"}],"version-history":[{"count":11,"href":"http:\/\/leanmagazine.net\/wp-json\/wp\/v2\/posts\/235\/revisions"}],"predecessor-version":[{"id":1083,"href":"http:\/\/leanmagazine.net\/wp-json\/wp\/v2\/posts\/235\/revisions\/1083"}],"wp:featuredmedia":[{"embeddable":true,"href":"http:\/\/leanmagazine.net\/wp-json\/wp\/v2\/media\/320"}],"wp:attachment":[{"href":"http:\/\/leanmagazine.net\/wp-json\/wp\/v2\/media?parent=235"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/leanmagazine.net\/wp-json\/wp\/v2\/categories?post=235"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/leanmagazine.net\/wp-json\/wp\/v2\/tags?post=235"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}