Ask product backlog users if the backlog works for them & you will invariably receive mixed responses. This is because there is often little uniformity in the way that organisations & users adopt & adapt the backlog. Significant elements of the process are sometimes omitted because they are deemed too difficult to implement. In addition, consumers of the information in the backlog only consider the details they need to carry out their role & don’t think about the up & downstream stakeholder requirements in finance, operations, human resources etc.
- Product backlogs invariably do not start at the point of origination, i.e. sales. This leads to duplication of effort relating to CRM & Agile project management tooling inputs. This also results in dual management reporting. These are challenges that can be easily remediated.
- Backlogs tend to focus on the details of the change, (we’ll come back to the quality of that in my next post), & do not always contain information relating to the assignees, their associated cost, start dates, end dates & dependencies. This impacts the ability of management & stakeholders to determine resource utilisation, & therefore the true cost of delivering the change. All of the following should impact prioritisation; changes should be modelled, the value of the change to the business determined, the cost of delivering the change estimated, the true time to deliver the change forecast based on resource availability.
- User stories are often listed by priority with little or no scientific method applied to the prioritisation. How many times have you reached the bottom end of the stack & identified Severity 1 & Severity 2 defects which put the deployment at risk? How many times has something been added to the backlog without an item being removed? How many times have you developed a change only to then realise the opportunity value is 5 or 6 times less than the cost of development?
- Little or no resource modelling is performed when determining what is going to be added to the backlog, bundling & value streams are often a distant memory. You will not garner efficiencies if you are not planning realistically.
- Management information is limited because team members are prone to cutting corners when inputting information into tracking tools, markers denoting status are not updated & the repositories contain dirty data. These short cuts all prevent informed decision making.
Whist I could add to this list of challenges, & I am certain as a reader & based on your experience you could too, what I wanted to convey that the above challenges are easily resolved.
At SQA Consulting we can provide you with an overarching dynamic dashboard that will initially enable you to identify & clean your dirty data, it will then enable you to visualise & manage delivery across your entire SDLC, refining your processes, saving you money, increasing the quality of your deliverables & enabling you to make informed decisions.
Sceptical? Get in touch, patrick.chatee@sqa-consulting.com or contact the Transformation Team, my team & I look forward to hearing from you.
