This article is the fourth in a series of articles on the subject of Agile theories
The power of Agile is that it leverages human behaviour as a means to achieve a goal. By understanding the theories behind the work being addressed, you can better utilise them and make the most of Agile. In this article I examine the Backlog and look at the relevant theories. We will examine these under the headings of
- Backlog
- User Story
Image Source: picjumbo.com
Backlog
The Backlog is the name given to the collection of features, tasks and ideas bundled together as a collection of unique short descriptions called User Stories. The goal of the Backlog is to identify, from it, a Minimal Viable Product (MVP) to bring to the market. This is done via the Product Vision and the individual Sprint Goals set by the Sprint Vision, as they iteratively lead to the initial Product Go-Live. Below, I have applied Simon Sinek’s Golden Circle Theory to the Scrum Product Vision triangle and set it on the foundation of the Agile Testing Pillars (described later). The Golden Circle questions;
· Why are we doing this? What is the belief that we wish to see in the world?
· How can we put a process in place to achieve the ‘why’? Allocate the specific Themes & Epics according to the Sprint Vision to achieve the Sprint Goal.
· What will we produce as the end result of the ‘why’? What is the proof that our belief has been realised through the Scrum delivery?
The Product Backlog is not just simply prioritised once (using the MoSCoW method, Cost of Delay (Reinertsen), Risk Based Scrum Method & noting the Pareto Principle) and then implemented as envisioned at the start of the project. It is added to, deleted from, modified, reprioritised, chunks are broken off & allocated to Sprints, while the remainder of the Backlog may undertake a redefinition of what it means to be marked as complete. It is governed by Chaos Theory. The ever-evolving unpredictable Backlog equates to Chaos. The Sprints bring about Stability (Order / Disorder Chaos). Chaos is reintroduced again through the Feedback offered by the Grooming / Refinement and Planning sessions - outside of the core activities within the Sprint. The Butterfly Effect can be seen in the way that small changes to the initial conditions (e.g.: Definition of Done & Garbage In, Garbage Out) lead to drastic changes in the result.
Within the Sprint Backlog, the Theory of Constraints (TOC) comes into play. The theory states that a chain is no stronger than its weakest link. Scrum has already identified and strengthened the weak links; Late integration of code is mitigated by continuous integration. Late testing is replaced by Test Driven Development. Late bug detection is offset by Pair Programming and Inspection & Adaptation. Queuing Theory, plays its part within the Sprint, as does Little's Law in reducing Work In Progress (WIP) levels to reduce average cycle time. However, some note that this Law is overstated.
As an aside, I have found it worthwhile representing the Sprint Themes & Epics in a colourised Pivot Bar graph. For me, this serves two purposes.
1. Goal Mapping; Clear mapping of Themes & Epics to the Sprint Goals
2. Stakeholder mapping; Clear mapping of Themes, Epics & Sprint Goals to Stakeholders within the Business, beyond the Product Owner.
When analysing this stacked bar graph, I look for clear blocks of colour within each bar to ensure that it aligns with the Sprint Goals. Next, I map each Theme (and sometimes Epics) back to a Stakeholder to ensure that their needs are clustered & satisfied. Once delivered, I encourage the Product Owner to recruit the relevant satisfied Stakeholders as champions for the Product.
Image source: picjumbo.com
User Story
Every idea (features, tasks, requirement) can be entertained as a User Story. It is captured, defined, categorised, viewed through the lens of a persona and the value that it creates is defined. Each User Story is specific, or SMART / INVEST, each one represents a Minimal Marketable Feature and each one is prioritised and earmarked to a Sprint based on the Product Vision by the Product Owner. As with any task, User Stories can be written efficiently (top tips) and inefficiently (common mistakes to avoid).
Each User Story has a number of attributes that have associated theories behind them;
The Definition of Done is an extremely powerful tool as it acts as a Social Contract on behalf of the Scrum Team members. It defines the criteria by which the Intrinsically Motivated team member will deliver the User Story back to the Scrum Team. While the Acceptance Criteria defines the boundaries of that User Story.
The spectre of Technical Debt is ever present. Technical Debt arises when code that is quick and easy to implement is used instead of applying the best solution; quickly leading to bugs & defects. Ward Cunningham observed that there is an increased effort for code changes as design entropy occurs, or put another way, it takes longer to fix the problem later than it does initially. This is confirmed by Lehmans Law which states that the older the code, the longer it will take to maintain it.
If bugs do make it into the Product, then the Broken Window Theory demonstrates the benefits of removing bugs as soon as they are identified as opposed to deferring them until later, as this will lead to a gradual degradation of the overall Product, unless they are actively rectified.
Great Agile Products stand upon the firm foundations of test strategy such as the 3 Agile Testing Pillars of:
- Automation and Tools (further details below)
- Software Testing (functional, non functional, exploratory, release based)
- Team Practices (Pair programming, code reviews, 3 amigos conversations)
Scrum benefits greatly from Automated Testing. Due to the nature of the incremental releases and the ‘touch once’ approach, you need to be able to have confidence in the fact that once a User Story is implemented it works and will work forever unless you specifically change it. The Automated Pyramid / Mountain provides a good guide for the appropriate level of attention that each activity deserves in terms of Unit tests, Service tests, GUI tests and lastly a light sprinkling of Manual tests.
This concludes my exploration and analysis of the underlying theories behind Agile, with a particular emphasis on Scrum. In time, I'm sure I'll find that the series wasn't exhaustive, but I hope that you have enjoyed reading / skimming some of it and maybe learned something along the way. If this article is actually your entry point into the series, then here are some quick links to the other articles on the subject of;
In a future article, it may be interesting to look at what happens when you purposefully go against the best practices applied to the multiple named theories and observe the probable outcomes.