SlideShare a Scribd company logo

Agile backlog management with Hansoft

•Download as PPTX, PDF•
•
Hansoft AB
Hansoft AB

This document discusses best practices for managing large product backlogs in agile development organizations using the backlog management tool Hansoft. It covers prioritizing and estimating the backlog, defining user stories and acceptance criteria, assigning ownership, and structuring the backlog. Techniques include stack ranking, estimating in story points or days, using MoSCoW prioritization, and customizing backlog views and columns. The document includes examples and exercises for prioritizing features, estimating work, and defining user stories in Hansoft.

1 of 98
Agile Backlog Management Practices in Hansoft to successfully handle large backlogs in product development organizations Hansoft is a backlog management tool you can download for free on www.hansoft.com This presentation was made using version 9.2042
This presentation covers these pillars of backlog management ▶ Prioritizing the backlog ▶ Estimating the backlog ▶ (Product) Ownership for just-in-time decision making ▶ Clarify and define acceptance criteria and user stories to understand underlying value ▶ Backlog structure ▶ Set (WIP) limits Hands on / Features Covered ▶ Finding the backlogs ▶ Basic prioritization and estimation ▶ Delegation and access to backlogs ▶ Defining new user stories and definition of done
Iterative projects: E.g. SCRUM Product Backlog Stage/Gate/Waterfallproject: E.g. Work Breakdown Structure (WBS) Flows What is a backlog? Icebox Cool Warm Hot Readiness backlog The backlog: Understand WHAT we should do The plan: Understand How and WHEN we will do it
User StoryGreat Idea Great Idea The Sprint Backlog 2-4 week sprints Sprint Planning Meeting Daily Standup Finished Work Demo Retro- spective Input from team, stakeholders, customers, managers Product Owner SCRUM Master The product and sprint backlog in SCRUM
Program/product Product roadmaps and release plans This is typically a ‘Product Backlog’ in Hansoft Team 3 Not yet selected Analysis Implementing Successful backlog management is at the core of scaling agile Portfolio High level business epics across all products This is typically a ’Portfolio Project’ in Hansoft Team 2 Increment 1 Linked to item Team 1Team/project Team backlogs and detailed implementation schedules. This is typically sub-projects in the planning view in Hansoft Commitment Note: This is an example and every organization is different. This is why Hansoft is highly flexible to adapt to your backlog needs.
Other types of backlogs 1) Bug Backlog -Inflow not as easy to control 2) Portfolio Backlog -Higher level items. Are we even working on the right product? 3) Individual backlogs -Todo lists and similar 6
Example of the development of a backlog Rough plan Release1Release2Release3 Sprint 1 Sprint 2 Detailed plan During the project Sprint 3 Sprint 4 S1 ended S2 Scope out? Seeforexample:https://www.slideshare.net/wasitova/product-backlog-management S3 S4
Why backlogs become fat 1) Hoarding: Backlogs tend to grow over time 2) There is a risk of everything becoming high priority 3) Lack of clear ownership 4) Multitasking: There are simply too many things the teams want to do at once 5) Time consuming discussions on low value items 6) Something of high prio for one person is low prio for another 8
Prioritization
What is your approach to prioritization? Lightweight approaches Example: First in, first out Beauracratic approaches Complicated and long analysis phases to develop business cases etc. Random Example: Ad hoc, gut feeling Systematic Example: Highly based on data Here?
The start is often an unordered backlog This is a product backlog item, “PBI” that would add value to the business if delivered.
… and stack rank it: There can only be one number 1 This is a highly efficient way to ensure that not everything becomes ‘Very High Priority’. Use ‘Show rank in list’ to see this priority in Hansoft. Stack ranking is done in the priority view.
Add a ”business value” proxy Estimating business value to a single number is difficult but common. Add any custom column in Hansoft to represent this.
… maybe add some categories The default Product Backlog priority column consist of 5 levels of priority. This can be easily changed to any other column that has the type ‘Drop list single choice’ by main managers.
Example of another categorization: MoSCoW Meaning Description MUST Describes a requirement that must be satisfied in the final solution for the solution to be considered a success. SHOULD Represents a high-priority item that should be included in the solution if it is possible. This is often a critical requirement but one which can be satisfied in other ways if strictly necessary. COULD Describes a requirement which is considered desirable but not necessary. This will be included if time and resources permit. WON'T Represents a requirement that stakeholders have agreed will not be implemented in a given release, but may be considered for the future. (note: occasionally the word "Would" is substituted for "Won't" to give a clearer understanding of this choice).Source: http://en.wikipedia.org/wiki/MoSCoW_method This is just a custom column of type drop list single choice that has been set to be the product backlog priority.
The Kano Model is useful to ensure that there is a mix of features being prioritized Learn more: http://en.wikipedia.org/wiki/Kano_model Dissatisfied Satisfied Not implemented Fully implemented Delighters, attractive features With this, the client will get paramount satisfaction but might not expect Over time, a delightful feature will become a basic need.
Eisenhower’s important/urgent principle Source: http://en.wikipedia.org/wiki/Time_management#The_Eisenhower_Method Use shift to sort on multiple columns
Category - Pareto Analysis 1) Typical applications: ● Only allow 20 % to be of high priority ● We can complete 80 % of the tasks in 20 % time - let’s prioritize the smallest 80 % 80 % 20 %
In the sprint plan, prioritise by technical dependencies 1 2 3 4 5 6 7
Exercise: Prioritize ▶ Define a way to prioritise your backlog ▶ Make it visual in Hansoft (custom columns, views, reports, dashboards etc.) ▶ Discussion: Would this make sense for you in your daily work? Does it make sense to your colleagues? 20
Estimation
Common techniques 1) Story Points: An abstract way to estimate decoupling size from time -Very useful in understanding velocity based on true progress -Can be easier for teams not used to do estimates 2) Estimated Days -How many ideal days (without interruption) would it take to complete the feature -Easy to understand for stakeholders -Can be hours as well 22
Easier alternatives 1) T-shirt size -XXS, XS, S, M, L, XL, XXL -Small enough, Big, Too Big 2) #NoEstimates -Iterate, don’t estimate -Estimation is waste 23
More complicated alternatives 1) Cost of delay -Give a monetary value on the cost if the backlog item is not delivered 2) Combining multiple columns -Use different columns to estimate for example strategic value, technical complexity reduction, usability improvement, cost of implementation etc. -Use a function column to get an index value of the importance 24 WSJF = 𝑈𝑠𝑒𝑟 𝐵𝑢𝑠𝑖𝑛𝑒𝑠𝑠 𝑉𝑎𝑙𝑢𝑒+𝑇𝑖𝑚𝑒 𝐶𝑟𝑖𝑡𝑖𝑐𝑎𝑙𝑖𝑡𝑦+𝑅𝑅𝑂𝐸 𝑉𝑎𝑙𝑢𝑒 𝐽𝑜𝑏 𝑆𝑖𝑧𝑒 RROE Value: Risk Reduction Opportunity Enablement Value
Low weight first Pick the smallest with highest cost of delay first Project Duration Cost of delay Weight = CoD / Duration 1 1 10 10 2 3 3 1 3 10 1 1 1 2 3 3 2 1 Delay Cost High weight first
Common pitfalls 1. Spending too much time to estimate items that are never likely to be implemented within scope of project 2. Too much focus on estimate vs. actuals, rather than as soon as possible or with sufficient quality. 3. Excessive time reporting bureaucracy 26
Exercise: Buy a feature! 1) List five current features that you would like to have (or we make some up) 2) Give each feature a size estimate in story points: 1, 2, 3, 5, 8 or 13 points. 3) Each person has 3 story coins – now invest your coins in the features you want and add it in a Hansoft backlog. 27
Backlog Ownership
Delegation Delegation is a key aspect of good backlog management Do not delegate to everyone, use it to make clear who is reponsible (team or person) The Product Owner Role is the most common solution 29
Exercise Make it visible to everyone in the team who is the owner of each section in the backlog. 30
Defining new user stories and definition of done
Working with user stories Definition of ready (INVEST): 1) Independent 2) Negotiable 3) Valuable 4) Estimable 5) Small enough 6) Testable 32 As a <type of user>, I want <some goal> so that <valuable reason>.
Why user stories? 1) User stories are the lowest level items in a product backlog 2) They are intended to be humanly readable and written so that both developers and customers can understand what they mean. 3) More importantly, they are the foundation of a good discussion 33
User stories in Hansoft 1) Specific flag 2) Keep the item name short and add the details in the user story field. 3) Examples of how to define acceptance criteria in the backlog. 34
Exercise: Work with User Stories 1. Add a couple of new user stories 2. Flag them as user stories and write the user story sentence in the appropriate field 3. Add Acceptance Criteria as a separate column 4. Show the user story in the backlog list 35
Structuring the product backlog
Backlog Structures ▶ Presentation ▶ Dimensions in the backlog (actors, processes, structure) ▶ Walk through some example backlogs ▶ Hands on / Features Covered ▶ Customizing the product and sprint backlog ▶ Structuring a backlog
Organization Process ComponentType of work Planning horizon Goal How do we generate value for our users?
Useful features in Hansoft to structure the backlog 1) Hierarchy 2) Columns (custom once particularly) 3) Workflows and pipelines 4) Reports 5) User view presets 6) Different views (planning vs. backlog) 39
Component Backlog On some level the component is typically included in the structure of a backlog. The main issue is that a user story typically affects multiple components so it becomes very difficult to manage.
Process Backlog Giving the process priority in structure means it is simple drag-and-drop to move from one stage to another. There are other mechanisms for capturing the process that also connects with default status
Organizational Backlog Works well with delegation feature. Usually the best starting point as backlogs tend to be per team so it is easy to work with. One drawback can be to get higher level understanding and managing dependencies between teams.
The Goal Driven Backlog The recommended way to break down a backlog in most agile context Gives very view overview and focus on value driven work towards the organization’s higher level goals Might be difficult to manage ownership in contexts with multiple product owners
Exercise 1) Build a backlog structure so that it is clear: -Who is going to work on each item -The process the item will follow to completion -Where in the product the change will happen 2) Discuss: What do you find most relevant levels in the backlog hierarchy? 44
Backlog Refinement Practices
Reduce Batch Size Value Delivered Time Delivery of small fine grained valuable work item Delivery of all items at once
Exercise: Batch Size Problem Working with an outsourcing partner, requirements are sent off in batches of 10 work items at the time with a fixed date for delivery. 1) Represent this in your project 2) Visualize the batch size Discussion: What are key constraints that control batch size? 47
Constrain WIP It is much easier to start work than it is to finish it. By controlling how much Work-in- Progress there is you can manage the finish line. 48
Visualise WIP 1) Defined as number of items in the status In Progress at any given time, create a report that clearly shows the current WIP 2) Right-click on a section in the backlog and select Create Dashboard Chart -Use “Status” as the dimension -“Number of items” as the measure 49
How many items can a person manage? 1) A good rule of thumb come’s from Dunbar’s number: 50 150
What do we do when we reach the limit? 1. Block new demand 2. Remove low-value items from queue 3. Flexible requirements 4. Apply extra resources 5. Part-time resources for high variability tasks 6. Pull high-powered experts to emerging bottlenecks 7. Develop T-shaped people that are deep in one area and broad in many 8. Cross-train people in adjacent processes 9. Use upstream mix changes to regulate queue size 51
Establish Cadence and Synchronization 1) Waiting times becomes predictable -Velocity helps understand and forecast capacity in sprint 2) Enables small batch sizes: -Compare Product backlog vs. sprint backlog 3) Limits the accumulation of variance 4) Fast feedback is enabled 5) 2-4 week synchronized sprints are recommended in SCRUM environments 52
Scenarios with different cadence
6. Decentralized Control 1) Centralize control for problems that are infrequent, large, or that have significant economies of scale. 2) The inefficiency of decentralization can cost less than than the value of faster response time 54
Exercise: Decentralize dependency resolution Problem Two teams are having many dependencies between each other. They pull their work from the same backlog in Hansoft. Be creative and create a structure that would help in dependency resolution so that it is easy: - Send a signal through Hansoft on the items that have a dependency - Add a report available to all project members with identified dependencies 55
Keep the product backlog in shape Refining the product backlog is a job, it is not something that can typically be done in the scope of a sprint planning meeting but is done continuously through interaction and collaboration with the Product Owner. 56
Allow for a process also in the backlog 1) There are several ways to capture a process: -Separate the backlog (Inbox, Backlog) -Setup workflows -Add custom columns 57 Raw Refined Accepted Committed
Aging Backlog 1) Create a report that filters everything that has not been updated in a year or more and is not in status Completion. Discussion: Are these ideas still relevant? 58
Workflows 1) States 2) Transitions 3) Connecting item status to the workflow 4) Simple review workflow 59
Setup a backlog workflow 1) Set up a simple workflow for implementing backlog items (Design, Implement, Test, Completed). 2) Make sure that only the testers can set an item to the workflow status Completed 3) When an item reaches the workflow state Completed the default status should automatically be set to Completed 4) Commit a few items from the backlog to the sprint 5) Tag a few stories in the sprint backlog to the workflow 60
Transport - Multiple Sources of Information  One system with one backlog  Setup projects with minimum need to duplicate information
Inventory - Keep More Information than Needed  Allow teams to work in different ways  Not everything has to be managed in Hansoft, items directly related to customer value to go into backlogs  Tightly manage the number of columns
Unnecessary Movement - People having to move to gain or access information  Learn how to create reports and use find in Hansoft to find relevant information  Do not only use Hansoft for status, also for feedback as a means to avoid meetings or to make them more efficient
Waiting - for data, late or wrong delivery  Develop in parallel where possible – and integrate often to validate  Use CFD’s to manage work in progress to shorten lead times and be able to better forecast delivery  Hansoft is a real time system – utilize that to always stay up to date on what work can get started
Over Production - Work that is not needed, reinventing the wheel  Share and learn good practices of how to use Hansoft  Break down large, high prio, requirements to smaller before starting to work on them to learn what work can be avoided  Before using pipelines, think through if it would make you more efficient or create work that is not needed.
Over Processing - Working more than necessary, working on wrong release, unclear requirements  Definition of Ready and Definition of Done is a good practice both for hardware and software teams  Tag work towards the same releases across hardware and software  Use allocation features to understand work load
Defects - Rewrite, redo, reschedule, rework, retest etc.  Use simple quality metrics in Hansoft: Are more bugs departing or arriving the bug queue?  Definition of ready and definition of done improves quality – do not sacrifice quality!
Metrics
Why we need metrics? 69
Backlog Metrics Presentation ▶ Agile Actionable Metrics – what is it? ▶ Quick intro to reports and dashboards ▶ Example Metrics Hands on / Features Covered ▶ Backlog quality metrics ▶ Velocity metrics ▶ Capacity metrics ▶ Custom metrics
Numberofitems Time Todo In progress Done Avg. Lead time Queue size Linear Process Cumulative Flow Diagrams
Numberofitems Time Todo In progress Done Monitoring queue size is more important than lead time
Example from a more traditional project Initiation Project Planning Project Execution Project Closure Time Completed In progress Remaining Scope Scope Creep
Setup a simple CFD 1) Create a chart on a new page called CFD 2) Add the project backlog items as filter 3) Add Historical data and Status completion as dimensions 4) Add number of items as measure 74
Agile metrics for everyone Important decision making happens everywhere in agile organizations. This is why each team, function and individual need access to relevant metrics to support the decisions they are responsible for. Hansoft empowers everyone, regardless of hierarchy, to track metrics and make better decisions. 75 Metrics are relevant on all levels
The Dashboards Section 76 A page is a collection of charts A chart or item view Use filters for each chart or item view Dimensions as legend or “Y- axis” Measures are the datapoints Control layout, colors and share
Example with Status 77
Filters can also be set on Measures 78
Visualise if high prio things are smaller 79
Can items fit into a sprint? 80
Is something happening? 81
Is the backlog prioritized? 82
How DEEP is your backlog? Problem As a Product Owner I want to identify if my backlog is DEEP 1) Setup a quality page in dashboards to visualize the quality of your backlog. For example: -Is every user story prioritized? -How many items are of highest priority? -How many of the items are estimated? -When were items last updated? 83
The Burndown Chart 84
Forcasting Setting On historical data dimension you have forecasting settings: Show a calculated forecast made by Hansoft Work with a custom forecast 85
Will we hit our milestone? 86
How is each team tracking towards completion? 87
Establish cadence 1) Setup a schedule with several synchronized sprints 2) Create a burndown chart showing the progress over several of these sprints 3) Clone the chart 4) Show a “best case” forecast in one chart and a “worst case” in the other. 88
Understanding Velocity over Time 89
Resource Efficiency vs. Flow Efficiency 90 ResourceEfficiency Flow Efficiency Strategy to increase utilization Strategy to fulfill needs asap Source: Niklas Modig and Håkan Forss
Resource Efficiency vs. Flow Efficiency 91 ResourceEfficiency Flow Efficiency Strategy to increase utilization Strategy to fulfill needs asap Source: Niklas Modig and Håkan Forss Lean Path
Work In Progress 92
Release Size 93
Allocation metrics 94
Resource Allocation Show Individual Allocation Allocation View 95
Summary 1) Backlog quality metrics: -Priortization charts -Estimation charts 2) Velocity Metrics -Sprint and release burndowns -Completed items per sprint 3) Capacity Metrics -Work in progress and batch size -Allocation metrics and views 96
Real Backlog Management 1) Identify your top 3 backlog management challenges within the project in your project group 2) Here are a few questions to get you started: -Is the backlog humanly readable? -How big is the backlog in total? -How much is WIP? -Is the ownership clear? -Are all columns being used and for what purpose? 97
Next steps ▶ Download and install Hansoft to try this yourself from www.hansoft.com ▶ Contact support@hansoft.com if you have any questions.

More Related Content

Agile backlog management with Hansoft

  • 1. Agile Backlog Management Practices in Hansoft to successfully handle large backlogs in product development organizations Hansoft is a backlog management tool you can download for free on www.hansoft.com This presentation was made using version 9.2042
  • 2. This presentation covers these pillars of backlog management ▶ Prioritizing the backlog ▶ Estimating the backlog ▶ (Product) Ownership for just-in-time decision making ▶ Clarify and define acceptance criteria and user stories to understand underlying value ▶ Backlog structure ▶ Set (WIP) limits Hands on / Features Covered ▶ Finding the backlogs ▶ Basic prioritization and estimation ▶ Delegation and access to backlogs ▶ Defining new user stories and definition of done
  • 3. Iterative projects: E.g. SCRUM Product Backlog Stage/Gate/Waterfallproject: E.g. Work Breakdown Structure (WBS) Flows What is a backlog? Icebox Cool Warm Hot Readiness backlog The backlog: Understand WHAT we should do The plan: Understand How and WHEN we will do it
  • 4. User StoryGreat Idea Great Idea The Sprint Backlog 2-4 week sprints Sprint Planning Meeting Daily Standup Finished Work Demo Retro- spective Input from team, stakeholders, customers, managers Product Owner SCRUM Master The product and sprint backlog in SCRUM
  • 5. Program/product Product roadmaps and release plans This is typically a ‘Product Backlog’ in Hansoft Team 3 Not yet selected Analysis Implementing Successful backlog management is at the core of scaling agile Portfolio High level business epics across all products This is typically a ’Portfolio Project’ in Hansoft Team 2 Increment 1 Linked to item Team 1Team/project Team backlogs and detailed implementation schedules. This is typically sub-projects in the planning view in Hansoft Commitment Note: This is an example and every organization is different. This is why Hansoft is highly flexible to adapt to your backlog needs.
  • 6. Other types of backlogs 1) Bug Backlog -Inflow not as easy to control 2) Portfolio Backlog -Higher level items. Are we even working on the right product? 3) Individual backlogs -Todo lists and similar 6
  • 7. Example of the development of a backlog Rough plan Release1Release2Release3 Sprint 1 Sprint 2 Detailed plan During the project Sprint 3 Sprint 4 S1 ended S2 Scope out? Seeforexample:https://www.slideshare.net/wasitova/product-backlog-management S3 S4
  • 8. Why backlogs become fat 1) Hoarding: Backlogs tend to grow over time 2) There is a risk of everything becoming high priority 3) Lack of clear ownership 4) Multitasking: There are simply too many things the teams want to do at once 5) Time consuming discussions on low value items 6) Something of high prio for one person is low prio for another 8
  • 10. What is your approach to prioritization? Lightweight approaches Example: First in, first out Beauracratic approaches Complicated and long analysis phases to develop business cases etc. Random Example: Ad hoc, gut feeling Systematic Example: Highly based on data Here?
  • 11. The start is often an unordered backlog This is a product backlog item, “PBI” that would add value to the business if delivered.
  • 12. … and stack rank it: There can only be one number 1 This is a highly efficient way to ensure that not everything becomes ‘Very High Priority’. Use ‘Show rank in list’ to see this priority in Hansoft. Stack ranking is done in the priority view.
  • 13. Add a ”business value” proxy Estimating business value to a single number is difficult but common. Add any custom column in Hansoft to represent this.
  • 14. … maybe add some categories The default Product Backlog priority column consist of 5 levels of priority. This can be easily changed to any other column that has the type ‘Drop list single choice’ by main managers.
  • 15. Example of another categorization: MoSCoW Meaning Description MUST Describes a requirement that must be satisfied in the final solution for the solution to be considered a success. SHOULD Represents a high-priority item that should be included in the solution if it is possible. This is often a critical requirement but one which can be satisfied in other ways if strictly necessary. COULD Describes a requirement which is considered desirable but not necessary. This will be included if time and resources permit. WON'T Represents a requirement that stakeholders have agreed will not be implemented in a given release, but may be considered for the future. (note: occasionally the word "Would" is substituted for "Won't" to give a clearer understanding of this choice).Source: http://en.wikipedia.org/wiki/MoSCoW_method This is just a custom column of type drop list single choice that has been set to be the product backlog priority.
  • 16. The Kano Model is useful to ensure that there is a mix of features being prioritized Learn more: http://en.wikipedia.org/wiki/Kano_model Dissatisfied Satisfied Not implemented Fully implemented Delighters, attractive features With this, the client will get paramount satisfaction but might not expect Over time, a delightful feature will become a basic need.
  • 17. Eisenhower’s important/urgent principle Source: http://en.wikipedia.org/wiki/Time_management#The_Eisenhower_Method Use shift to sort on multiple columns
  • 18. Category - Pareto Analysis 1) Typical applications: ● Only allow 20 % to be of high priority ● We can complete 80 % of the tasks in 20 % time - let’s prioritize the smallest 80 % 80 % 20 %
  • 19. In the sprint plan, prioritise by technical dependencies 1 2 3 4 5 6 7
  • 20. Exercise: Prioritize ▶ Define a way to prioritise your backlog ▶ Make it visual in Hansoft (custom columns, views, reports, dashboards etc.) ▶ Discussion: Would this make sense for you in your daily work? Does it make sense to your colleagues? 20
  • 22. Common techniques 1) Story Points: An abstract way to estimate decoupling size from time -Very useful in understanding velocity based on true progress -Can be easier for teams not used to do estimates 2) Estimated Days -How many ideal days (without interruption) would it take to complete the feature -Easy to understand for stakeholders -Can be hours as well 22
  • 23. Easier alternatives 1) T-shirt size -XXS, XS, S, M, L, XL, XXL -Small enough, Big, Too Big 2) #NoEstimates -Iterate, don’t estimate -Estimation is waste 23
  • 24. More complicated alternatives 1) Cost of delay -Give a monetary value on the cost if the backlog item is not delivered 2) Combining multiple columns -Use different columns to estimate for example strategic value, technical complexity reduction, usability improvement, cost of implementation etc. -Use a function column to get an index value of the importance 24 WSJF = 𝑈𝑠𝑒𝑟 𝐵𝑢𝑠𝑖𝑛𝑒𝑠𝑠 𝑉𝑎𝑙𝑢𝑒+𝑇𝑖𝑚𝑒 𝐶𝑟𝑖𝑡𝑖𝑐𝑎𝑙𝑖𝑡𝑦+𝑅𝑅𝑂𝐸 𝑉𝑎𝑙𝑢𝑒 𝐽𝑜𝑏 𝑆𝑖𝑧𝑒 RROE Value: Risk Reduction Opportunity Enablement Value
  • 25. Low weight first Pick the smallest with highest cost of delay first Project Duration Cost of delay Weight = CoD / Duration 1 1 10 10 2 3 3 1 3 10 1 1 1 2 3 3 2 1 Delay Cost High weight first
  • 26. Common pitfalls 1. Spending too much time to estimate items that are never likely to be implemented within scope of project 2. Too much focus on estimate vs. actuals, rather than as soon as possible or with sufficient quality. 3. Excessive time reporting bureaucracy 26
  • 27. Exercise: Buy a feature! 1) List five current features that you would like to have (or we make some up) 2) Give each feature a size estimate in story points: 1, 2, 3, 5, 8 or 13 points. 3) Each person has 3 story coins – now invest your coins in the features you want and add it in a Hansoft backlog. 27
  • 29. Delegation Delegation is a key aspect of good backlog management Do not delegate to everyone, use it to make clear who is reponsible (team or person) The Product Owner Role is the most common solution 29
  • 30. Exercise Make it visible to everyone in the team who is the owner of each section in the backlog. 30
  • 31. Defining new user stories and definition of done
  • 32. Working with user stories Definition of ready (INVEST): 1) Independent 2) Negotiable 3) Valuable 4) Estimable 5) Small enough 6) Testable 32 As a <type of user>, I want <some goal> so that <valuable reason>.
  • 33. Why user stories? 1) User stories are the lowest level items in a product backlog 2) They are intended to be humanly readable and written so that both developers and customers can understand what they mean. 3) More importantly, they are the foundation of a good discussion 33
  • 34. User stories in Hansoft 1) Specific flag 2) Keep the item name short and add the details in the user story field. 3) Examples of how to define acceptance criteria in the backlog. 34
  • 35. Exercise: Work with User Stories 1. Add a couple of new user stories 2. Flag them as user stories and write the user story sentence in the appropriate field 3. Add Acceptance Criteria as a separate column 4. Show the user story in the backlog list 35
  • 37. Backlog Structures ▶ Presentation ▶ Dimensions in the backlog (actors, processes, structure) ▶ Walk through some example backlogs ▶ Hands on / Features Covered ▶ Customizing the product and sprint backlog ▶ Structuring a backlog
  • 38. Organization Process ComponentType of work Planning horizon Goal How do we generate value for our users?
  • 39. Useful features in Hansoft to structure the backlog 1) Hierarchy 2) Columns (custom once particularly) 3) Workflows and pipelines 4) Reports 5) User view presets 6) Different views (planning vs. backlog) 39
  • 40. Component Backlog On some level the component is typically included in the structure of a backlog. The main issue is that a user story typically affects multiple components so it becomes very difficult to manage.
  • 41. Process Backlog Giving the process priority in structure means it is simple drag-and-drop to move from one stage to another. There are other mechanisms for capturing the process that also connects with default status
  • 42. Organizational Backlog Works well with delegation feature. Usually the best starting point as backlogs tend to be per team so it is easy to work with. One drawback can be to get higher level understanding and managing dependencies between teams.
  • 43. The Goal Driven Backlog The recommended way to break down a backlog in most agile context Gives very view overview and focus on value driven work towards the organization’s higher level goals Might be difficult to manage ownership in contexts with multiple product owners
  • 44. Exercise 1) Build a backlog structure so that it is clear: -Who is going to work on each item -The process the item will follow to completion -Where in the product the change will happen 2) Discuss: What do you find most relevant levels in the backlog hierarchy? 44
  • 46. Reduce Batch Size Value Delivered Time Delivery of small fine grained valuable work item Delivery of all items at once
  • 47. Exercise: Batch Size Problem Working with an outsourcing partner, requirements are sent off in batches of 10 work items at the time with a fixed date for delivery. 1) Represent this in your project 2) Visualize the batch size Discussion: What are key constraints that control batch size? 47
  • 48. Constrain WIP It is much easier to start work than it is to finish it. By controlling how much Work-in- Progress there is you can manage the finish line. 48
  • 49. Visualise WIP 1) Defined as number of items in the status In Progress at any given time, create a report that clearly shows the current WIP 2) Right-click on a section in the backlog and select Create Dashboard Chart -Use “Status” as the dimension -“Number of items” as the measure 49
  • 50. How many items can a person manage? 1) A good rule of thumb come’s from Dunbar’s number: 50 150
  • 51. What do we do when we reach the limit? 1. Block new demand 2. Remove low-value items from queue 3. Flexible requirements 4. Apply extra resources 5. Part-time resources for high variability tasks 6. Pull high-powered experts to emerging bottlenecks 7. Develop T-shaped people that are deep in one area and broad in many 8. Cross-train people in adjacent processes 9. Use upstream mix changes to regulate queue size 51
  • 52. Establish Cadence and Synchronization 1) Waiting times becomes predictable -Velocity helps understand and forecast capacity in sprint 2) Enables small batch sizes: -Compare Product backlog vs. sprint backlog 3) Limits the accumulation of variance 4) Fast feedback is enabled 5) 2-4 week synchronized sprints are recommended in SCRUM environments 52
  • 54. 6. Decentralized Control 1) Centralize control for problems that are infrequent, large, or that have significant economies of scale. 2) The inefficiency of decentralization can cost less than than the value of faster response time 54
  • 55. Exercise: Decentralize dependency resolution Problem Two teams are having many dependencies between each other. They pull their work from the same backlog in Hansoft. Be creative and create a structure that would help in dependency resolution so that it is easy: - Send a signal through Hansoft on the items that have a dependency - Add a report available to all project members with identified dependencies 55
  • 56. Keep the product backlog in shape Refining the product backlog is a job, it is not something that can typically be done in the scope of a sprint planning meeting but is done continuously through interaction and collaboration with the Product Owner. 56
  • 57. Allow for a process also in the backlog 1) There are several ways to capture a process: -Separate the backlog (Inbox, Backlog) -Setup workflows -Add custom columns 57 Raw Refined Accepted Committed
  • 58. Aging Backlog 1) Create a report that filters everything that has not been updated in a year or more and is not in status Completion. Discussion: Are these ideas still relevant? 58
  • 59. Workflows 1) States 2) Transitions 3) Connecting item status to the workflow 4) Simple review workflow 59
  • 60. Setup a backlog workflow 1) Set up a simple workflow for implementing backlog items (Design, Implement, Test, Completed). 2) Make sure that only the testers can set an item to the workflow status Completed 3) When an item reaches the workflow state Completed the default status should automatically be set to Completed 4) Commit a few items from the backlog to the sprint 5) Tag a few stories in the sprint backlog to the workflow 60
  • 61. Transport - Multiple Sources of Information  One system with one backlog  Setup projects with minimum need to duplicate information
  • 62. Inventory - Keep More Information than Needed  Allow teams to work in different ways  Not everything has to be managed in Hansoft, items directly related to customer value to go into backlogs  Tightly manage the number of columns
  • 63. Unnecessary Movement - People having to move to gain or access information  Learn how to create reports and use find in Hansoft to find relevant information  Do not only use Hansoft for status, also for feedback as a means to avoid meetings or to make them more efficient
  • 64. Waiting - for data, late or wrong delivery  Develop in parallel where possible – and integrate often to validate  Use CFD’s to manage work in progress to shorten lead times and be able to better forecast delivery  Hansoft is a real time system – utilize that to always stay up to date on what work can get started
  • 65. Over Production - Work that is not needed, reinventing the wheel  Share and learn good practices of how to use Hansoft  Break down large, high prio, requirements to smaller before starting to work on them to learn what work can be avoided  Before using pipelines, think through if it would make you more efficient or create work that is not needed.
  • 66. Over Processing - Working more than necessary, working on wrong release, unclear requirements  Definition of Ready and Definition of Done is a good practice both for hardware and software teams  Tag work towards the same releases across hardware and software  Use allocation features to understand work load
  • 67. Defects - Rewrite, redo, reschedule, rework, retest etc.  Use simple quality metrics in Hansoft: Are more bugs departing or arriving the bug queue?  Definition of ready and definition of done improves quality – do not sacrifice quality!
  • 69. Why we need metrics? 69
  • 70. Backlog Metrics Presentation ▶ Agile Actionable Metrics – what is it? ▶ Quick intro to reports and dashboards ▶ Example Metrics Hands on / Features Covered ▶ Backlog quality metrics ▶ Velocity metrics ▶ Capacity metrics ▶ Custom metrics
  • 71. Numberofitems Time Todo In progress Done Avg. Lead time Queue size Linear Process Cumulative Flow Diagrams
  • 73. Example from a more traditional project Initiation Project Planning Project Execution Project Closure Time Completed In progress Remaining Scope Scope Creep
  • 74. Setup a simple CFD 1) Create a chart on a new page called CFD 2) Add the project backlog items as filter 3) Add Historical data and Status completion as dimensions 4) Add number of items as measure 74
  • 75. Agile metrics for everyone Important decision making happens everywhere in agile organizations. This is why each team, function and individual need access to relevant metrics to support the decisions they are responsible for. Hansoft empowers everyone, regardless of hierarchy, to track metrics and make better decisions. 75 Metrics are relevant on all levels
  • 76. The Dashboards Section 76 A page is a collection of charts A chart or item view Use filters for each chart or item view Dimensions as legend or “Y- axis” Measures are the datapoints Control layout, colors and share
  • 78. Filters can also be set on Measures 78
  • 79. Visualise if high prio things are smaller 79
  • 80. Can items fit into a sprint? 80
  • 82. Is the backlog prioritized? 82
  • 83. How DEEP is your backlog? Problem As a Product Owner I want to identify if my backlog is DEEP 1) Setup a quality page in dashboards to visualize the quality of your backlog. For example: -Is every user story prioritized? -How many items are of highest priority? -How many of the items are estimated? -When were items last updated? 83
  • 85. Forcasting Setting On historical data dimension you have forecasting settings: Show a calculated forecast made by Hansoft Work with a custom forecast 85
  • 86. Will we hit our milestone? 86
  • 87. How is each team tracking towards completion? 87
  • 88. Establish cadence 1) Setup a schedule with several synchronized sprints 2) Create a burndown chart showing the progress over several of these sprints 3) Clone the chart 4) Show a “best case” forecast in one chart and a “worst case” in the other. 88
  • 90. Resource Efficiency vs. Flow Efficiency 90 ResourceEfficiency Flow Efficiency Strategy to increase utilization Strategy to fulfill needs asap Source: Niklas Modig and Håkan Forss
  • 91. Resource Efficiency vs. Flow Efficiency 91 ResourceEfficiency Flow Efficiency Strategy to increase utilization Strategy to fulfill needs asap Source: Niklas Modig and Håkan Forss Lean Path
  • 95. Resource Allocation Show Individual Allocation Allocation View 95
  • 96. Summary 1) Backlog quality metrics: -Priortization charts -Estimation charts 2) Velocity Metrics -Sprint and release burndowns -Completed items per sprint 3) Capacity Metrics -Work in progress and batch size -Allocation metrics and views 96
  • 97. Real Backlog Management 1) Identify your top 3 backlog management challenges within the project in your project group 2) Here are a few questions to get you started: -Is the backlog humanly readable? -How big is the backlog in total? -How much is WIP? -Is the ownership clear? -Are all columns being used and for what purpose? 97
  • 98. Next steps ▶ Download and install Hansoft to try this yourself from www.hansoft.com ▶ Contact support@hansoft.com if you have any questions.

Editor's Notes

  1. Om vi tar ett steg tillbaka och pratar om definitioner. Alla dessa bolag har backlogs i en vidare mening. Begränsade resurser, begränsad tid, föränderliga krav (till viss del).
  2. Tre steg i ett projekt Att kunna arbeta på det här sättet - det är en konstform!
  3. Den centrala frågan för hur man ska strukturera sin backlog är utifrån värdeleverans. Vi måste våga strukturera om våra backlogs ordentligt om man ska ha möjlighet att få förändringskraft. Och att sedan man balanserar olika dimensioner. Tänk er att man till exempel blir besatt av sin WBS av komponenter – det blir ett helt tekniskt härke. Eller att man blir besatt av sin kanban-tavla, processen stannar upp. Jag har sett många backlogs som helt har saknat koppling till någon förm av övergripande mål. Notera att vi här inte hanterar kostnad/budget direkt. Det är lite medvetet då det finns många bra exempel på där man lyfter budgetfrågan till en högra nivå kring resurser som är tillgängliga kontinuerligt istället i fasta team.
  4. Reduce batch time as it is one of the cheapest, simplest and most powerful ways to reduce variability and queues.
  5. It is a trade-off between transaction cost and holding cost
  6. Dunbar’s number
  7. Example: Backlog structure with one for team. The teams use the delegation functionality to add work for each other.
  8. Tool 4: Cumulative Flow Diagrams
  9. Agile metrics for everyone Important decision making happens everywhere in agile organizations. This is why each team, function and individual need access to relevant metrics to support the decisions they are responsible for. Hansoft empowers everyone, regardless of hierarchy, to track metrics and make better decisions.