{"id":36,"date":"2021-08-18T08:01:35","date_gmt":"2021-08-18T08:01:35","guid":{"rendered":"https:\/\/agilerasmus.com\/playbook\/?page_id=36"},"modified":"2021-08-30T13:02:39","modified_gmt":"2021-08-30T13:02:39","slug":"priority","status":"publish","type":"page","link":"https:\/\/playbook.agilerasmus.com\/index.php\/priority\/","title":{"rendered":"Priority"},"content":{"rendered":"\n
\"\"<\/figure>\n\n\n\n

Epic is prioritized based on cost, business value, opportunities, etc. It will start as a rough idea and be prioritized on the Portfolio Kanban.<\/p>\n\n\n\n

Identify user<\/h2>\n\n\n\n
Who<\/strong><\/td>Product Owner<\/a> and Developers<\/a><\/td><\/tr>
Why<\/strong><\/td>Working on a new idea it is crucial to identify the receiver to collaborate towards a success<\/td><\/tr>
What<\/strong><\/td>Discuss with the author of the idea on who would be the potential receiver and user of the outcome<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Define benefit<\/h2>\n\n\n\n
Who<\/strong><\/td>Product Owner<\/a>, Customer and Developers<\/a><\/td><\/tr>
Why<\/strong><\/td>New ideas should always be beneficial for the user, otherwise it should be cancelled<\/td><\/tr>
What<\/strong><\/td>Collaborate with the user to define the benefit of the idea. The benefit could be described in many ways: economical, increase in user base, etc. It may be a good idea to define the benefit using Business Value Game<\/a>.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Pretotype<\/h2>\n\n\n\n
Who<\/strong><\/td>Product Owner<\/a>, Customer and Developers<\/a><\/td><\/tr>
Why<\/strong><\/td>Illustrate the idea to confirm benefit and feasibility<\/td><\/tr>
What<\/strong><\/td>Build a cheap sketch, illustration or mockup with out investing in development. The purpose is to validate that the user can benefit from the outcome and to verify that the team is able to build it. Depending on the idea it will be a good idea use some of the following techniques: Pretotyping<\/a>, Design Sprint<\/a>, Shaping<\/a>, Hackathon<\/a>, Mob-programming<\/a>, etc.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Brutal estimate<\/h2>\n\n\n\n
Who<\/strong><\/td>Developers<\/a><\/td><\/tr>
Why<\/strong><\/td>The brutal estimate is used for prioritizing the idea against other great ideas<\/td><\/tr>
What<\/strong><\/td>Based on the pretotype the idea can be relatively estimated using Story Points<\/a>, T-Shirt Sizing<\/a>, etc.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Portfolio Kanban<\/h2>\n\n\n
\n\n\n\n\n\n
Who<\/strong><\/td>\nProduct Owner<\/a> and Customers <\/a>are key persons. Scrum Master<\/a> facilitates.<\/td>\n<\/tr>\n
Why<\/strong><\/td>\nTo visualize flow and discuss priorities, ranking and impediments<\/td>\n<\/tr>\n
What<\/strong><\/td>\n\n

Update the Portfolio Kanban at the recurring Portfolio Scrum event.<\/p>\n

The Portfolio Kanban<\/a> is a board showing the state of the Product Backlog. It visualizes the flow of work items processed by the Developers<\/a>. Product Owner and Customers collaborate on ranking and prioritising the Product Backlog. Impediments raised by the Developers can be discussed to determine if the investment in active work items is still relevant or if something else needs to be prioritised.<\/p>\n

\u00a0<\/p>\n

The portfolio kanban meeting should be as often as needed. Ideally once a week.<\/p>\n

Typical agenda for the meeting:<\/p>\n