State of mind
Testability of the Product Backlog
The Product Backlog is understandable to the Customer
State of mindWhy you should test product backlog
A Customer centric organisation leads to a simple criterion on assessing a Product Backlog: Customers must understand the Product Backlog Items (PBI) [Larman 2010].
However, business needs may require some technical prerequisites, training or compliance checks that may impact several business needs notably through Non Functional Requirements (NFR) , usually for exploitability matters or certifications. Those non-business needs are named “enablers” in the SAFe framework [SAFe 2021-23].
Moreover, when it comes to large organizations, it appears that PBI ideation becomes a kind of process that aims to [SAFe 2021-28] [Larman 2017] [Schwaber 2020]:
refine the need to reach what is needed in order to discover enough details on the business needs
split the PBI into smaller chunks that the organization can cope regarding both team sizes and time slices that fit cadences [Larman 2010][Lawrence 2012] [Le Lan 2018][Moustier 2020]
For that matter, agile encourages people participation [Beck 2001] from different point of views notably users, business and technical matters, should it be with large organizations [Larman 2010] [SAFe 2021-32] [SAFe 2021-29] [Brandolini 2019][Moustier 2020] or small teams [Schwaber 2020] (e.g. with 3 Amigos mode).
Unfortunately, Conway’s law [Conway 1968] leads usually the hierarchy to build organizations around components instead of relying on features. Component-oriented teams tend to forget about the end users' needs while Feature teams are much closer to genuine necessities since it is easier for them to do Gemba walks .
Even if Managers don’t fall into Conway’s law pitfall, it appears that large teams are limited to the Dunbar number [Dunbar 1992] [Moustier 2020], i.e. a team composed with 150 people maximum to keep the members aligned and synchronized on a vision. Alas, designing an organization exclusively with customer-facing teams is quite a challenge.
For that reason, SAFe tackles this issue with business-facing teams (Agile Release Trains - ARTs) along with supporting ARTs [SAFe 2021-31] with guardrails [SAFe 2021-33] to keep the structure aligned with the business objectives: while implementation teams guess the underlying business objectives, Business Owner score each of them with a business value [SAFe 2021-30].
Impact on the testing maturity
There should be a unique backlog shared across teams [Larman 2010] [Schwaber 2020] [Moustier 2020] which should be
“DEEP” [Deemer 2012][Moustier 2020]:
Detailed appropriately
Estimated
Emergent
Prioritized
Regularly revised thanks to a 5S approach
Kept small to avoid huge amount of pending work - this can be achieved by applying Theory of Constraints
Whatever the size of the organization, the PBI included in the product backlog should
Be customer centric or aligned with the business objectives with the highest added value - traceability should be used to enable monitoring
Be Feasible by assigned teams within the iteration (or within the budget guardrails [SAFe 2021-33] when it comes to never ending matters such as epics/value streams [SAFe 2021-31])
Be INVEST / SMART [Wake 2003] [Moustier 2019-1]
Include such as health monitoring criteria such as
Leading Indicators [SAFe 2021-34]
Functional acceptance criteria
NFR compliances criteria from the four quadrants [Marick 2003][Bach 2014][Crispin 2021]or [ISO 25010 2011]
a DoD
Be consistent with
a DoR
the terms already provided - see Ubiquitary Language
other parts (dependencies, teams, etc .)
business objectives [SAFe 2021-30]
Be shared and explained with appropriate stakeholders for testability is also a matter of knowing the existence of the testing means [Bach 2015a] [MoT 2019] [Moustier 2020]
To ease the testability of the backlog, PanTesting is also helpful to keep back lines aware of the business stakes.
Agilitest’s standpoint on product backlog testability
Whilst Agilitest’s assets focus mainly on automating test scripts, it is inevitable to rely on a good product backlog testability because it facilitates:
visibility on scheduling automation
automating the right test cases with the appropriate means to provide the expected feedbacks
To discover the whole set of practices, click here .