![\"\"](\"http:\/\/www.vilma-consulting.dk\/wp-content\/uploads\/2017\/11\/money-2724241_1920-300x203.jpg\")
<\/p>\n
In the ideal world, the list of requirements, the Product Backlog, is always in perfect condition; that is, it is well specified; both in terms of what is needed and what is not<\/em> needed, but also the desired quality to be delivered. Further, the product backlog is chunked in feasible parts, for the development team to deliver within a sprint, and finally uniquely prioritized by importance to avoid misunderstandings.<\/p>\n The preparatory work of planning the delivered output at the end of the sprint, is organized efficiently<\/strong> as answers are present, and predictable<\/strong> as adequate information supports the sizing of items and hence, the forming of the overall expectation for the sprints delivery, the sprint goal. During the sprint expectations are managed<\/strong>, as and when something happens. Yet, the team is able to consistently deliver on the promises made.<\/p>\n Yep, just as most of us do. Things break, rules change, competition strikes, basically ANYTHING can happen on an ordinary day at work. How well we handle that, tends to come down to how well we prepared to handle the unknown.<\/p>\n To get an indication of how well you do, you need to know what you are overall aiming at. What is important for your company, for the team and maybe some shareholders?<\/p>\n Once the objective is known, start collecting data and measure the objective, diligently and consistently over time. Add visibility by continuously share the number(s) with the team, celebrate the improvements big and small \u2013 and you will get more improvements.<\/p>\n In a trust-based environment, the striving for team success will reveal all the places with transfers of knowledge, that can be improved. And these, by and large, involves the Product Owner and (part of) the team, no matter whether it is about collecting the information, effectively structuring the information, distributing the information or being available for additional information on any of the items \u2013 for both team and stakeholders.<\/p>\n So in short, the Product Owner can make or break, the productivity<\/strong>.<\/p>\n To get to that level of understanding, you can either start turning every stone, or, team up with an Agile Specialist<\/a>\u00a0 that can guide you on which stones to turn and get the results faster.<\/p>\n <\/p>\n Good luck with your agile journey!<\/p>\n Majken Vildrik Thougaard<\/strong><\/em>, Independent Agile Specialist & Owner VILMA Consulting<\/p>\n <\/p>\n PS: The Product Owner cannot do magic, so please make sure the Product Owner is empowered to succeed <\/strong>in the role!<\/p>\n","protected":false},"excerpt":{"rendered":" Is it that simple? Yes! Never underestimate the value of a really, really good Product Owner, as the Product Owner can make or break, the productivity \u2013 in some cases even without knowing. Well, let\u2019s first rewind the story a bit. In the ideal world, the list of requirements, the Product Backlog, is always in … <\/p>\nBut, I live in the real world!<\/strong><\/h4>\n
So what should I do?<\/strong><\/h4>\n
\n
But WHY will things improve?<\/strong><\/h4>\n