{"id":126,"date":"2010-06-14T12:07:00","date_gmt":"2010-06-14T12:07:00","guid":{"rendered":"http:\/\/agilepartnership.com\/?p=126"},"modified":"2010-06-14T12:07:00","modified_gmt":"2010-06-14T12:07:00","slug":"the-so-called-polluted-product-backlog","status":"publish","type":"post","link":"https:\/\/agilepartnership.com\/fr\/the-so-called-polluted-product-backlog\/","title":{"rendered":"The so-called polluted Product Backlog"},"content":{"rendered":"

\"\"<\/a><\/p>\n

Warning: The following post might provoke a mild aneurism<\/em> to some scrum purists.<\/em><\/span><\/p>\n

Don\u2019t you love a nice, clean and deep <\/a>Product Backlog, filled only with strong user stories tightly linked to clear business objectives and estimated by business value and story points?\u00a0 As an Agile coach working with large organization with even larger challenges, I don\u2019t usually have that luxury. And If I do, I don\u2019t believe it!\u00a0 The amount of stuff that needs to be done to ship out quality software is astronomical and never ceases to amaze me. So of course the \u201cDefinition of DONE\u201d is equally immense.<\/p>\n

The definition of DONE<\/strong><\/p>\n

Creating and shipping software in large organizations involves tasks and deliverables that go beyond straightforward testing, coding and releasing.\u00a0 To get all this work out into the open, I ask teams to focus on a couple of \u201cjuicy\u201d user stories and ask them to identify ALL that needs to be completed to get this product in front of the user.\u00a0 We might get something like this:<\/p>\n

\"\"<\/a> <\/span><\/p>\n

And the list goes on and on…<\/p>\n

Teams are then challenged to get everything done within a user story.\u00a0\u00a0 Of course this is impossible.\u00a0 The best the team (and the supporting organization) can do for now is to complete some DONE items at the sprint, milestone, release or project level (see fig.1)<\/p>\n

Figure 1<\/p>\n

\"\"<\/a><\/p>\n

The further away we are from the user story level, the more nervous I get. At the beginning of an Agile transition, I can live with that as long as we identify these \u201cnon-story DONEs\u201d as debt and we manage it appropriately.\u00a0 I don\u2019t judge or question any of the DONE items (ok, maybe I do, but not out loud) But I do want to the team and the organization to clearly see the sheer volume of overhead and offer them some kind of tool to start cutting out the fat.<\/p>\n

This tool will be…The Product Backlog<\/strong>.<\/span><\/p>\n

The team will manage this debt by adding non-functional work items in the Product Backlog.\u00a0 In other words, all DONE items not included within a user story will become a work item in the Backlog. <\/strong>If the team’s initial estimate is 4 sprints for a release, then those sprint-level DONE items will appear four times. <\/strong>This continues with milestone, release and project DONE items. This makes for one polluted Backlog<\/strong> – And that\u2019s ok…For now!\u00a0 As you can imagine, this can double the scope of the project.<\/span><\/p>\n

A product backlog can go from this:<\/span><\/p>\n

\"\"<\/a><\/span><\/p>\n


\n<\/a><\/span><\/p>\n

To this:<\/span><\/p>\n

\"\"<\/a><\/span><\/p>\n

<\/span>What does it mean?<\/strong><\/span><\/p>\n

Based on the team\u2019s velocity, it\u2019ll probably take 4 to 5 sprints complete the project and not 2 – That is, if nothing changes. It means that it won\u2019t take 15 points to produce $26,000 in business value but at least 33. Nasty!<\/span><\/p>\n

It can also show an organization that went through a chaotic period and decided to structure all that is I.T. into a defined process; a normal reaction. Over design and over documentation is heavy and expensive, but it\u2019s still better than the anarchy of the early years.<\/span><\/p>\n

Finally, it means we need find the correct balance for this project and organization.<\/span><\/p>\n

What do we do?<\/strong><\/span><\/p>\n

If the organization is polluted, so shall be the Product Backlog – Deal with it! No really, you need to deal with it.<\/span><\/p>\n

The Product Backlog can\u2019t remain in that state. It\u2019s needs to be filled, almost exclusively, with items that deliver business value.\u00a0 That said, don\u2019t hide the real work that currently needs to be done or simply take that work into consideration by inflating story points.\u00a0 It needs to be out there, for all to see.\u00a0 We want to provoke a sense of urgency and change.<\/span><\/p>\n

All the $0 business value items are now action items, things that a Scrum team and the surrounding organization need to deal with now. \u00a0If we can\u2019t eliminate an item all together (Ex.: Code document? \u2013 I mean come on!), then we need to find out how we can reduce the effort needed to get it done.\u00a0 We need to reduce waste and those dollars signs might motivate those upper management folks to get things moving.<\/span><\/p>\n

This approach is provocative but in many large organizations, shock and awe is often required to encourage change.\u00a0 If a Product Owner and ScrumMaster can clearly show that it costs $1 to create $0.25 of value, I promise you that something will happen.<\/span><\/p>\n

So between a polluted Product Backlog and a clean one that doesn\u2019t show us the full picture, I choose the former…For now! \ud83d\ude09<\/span><\/p>","protected":false},"excerpt":{"rendered":"

Warning: The following post might provoke a mild aneurism to some scrum purists. Don\u2019t you love a nice, clean and deep Product Backlog, filled only with strong user stories tightly linked to clear business objectives and estimated by business value and story points?\u00a0 As an Agile coach working with large organization with even larger challenges, […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"footnotes":""},"categories":[17,18],"tags":[],"class_list":["post-126","post","type-post","status-publish","format-standard","hentry","category-agile","category-scrum"],"acf":[],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/agilepartnership.com\/fr\/wp-json\/wp\/v2\/posts\/126","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/agilepartnership.com\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/agilepartnership.com\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/agilepartnership.com\/fr\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/agilepartnership.com\/fr\/wp-json\/wp\/v2\/comments?post=126"}],"version-history":[{"count":0,"href":"https:\/\/agilepartnership.com\/fr\/wp-json\/wp\/v2\/posts\/126\/revisions"}],"wp:attachment":[{"href":"https:\/\/agilepartnership.com\/fr\/wp-json\/wp\/v2\/media?parent=126"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/agilepartnership.com\/fr\/wp-json\/wp\/v2\/categories?post=126"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/agilepartnership.com\/fr\/wp-json\/wp\/v2\/tags?post=126"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}