Agile frameworks, customer and user experience (CX/UX), and big data are highly topical and have necessitated a shift in language and awareness towards a focus on why something is being built. A positive aspect of Agile is how frameworks can be implemented in many different ways e.g. Scrum is not as prescriptive about how things need to be done as traditional project management methodologies such as PRINCE2.
However, there are some aspects that require due diligence when implementing an Agile framework. These aspects are primarily focused on technical best practices, with minimal focus on the psychological implication of something as “trivial” as terminology, rather focusing on the value delivered to the end-customer.
Why is the term “ticket” a problem?
Terminology and thinking are highly correlated, and careless terminology often leads to careless thinking. Scrum and Agile vocabulary is constantly being updated as more is learnt about these methodologies, to ensure the terminology does not interfere with the thinking behind the way to do things.
An example is how a sprint “commit” has been changed to a sprint “estimate”, to stop the management structures holding the teams unfairly accountable for not meeting their “commitment” to finishing all stories within the sprint.
Additionally, Agile42 recently changed from “prioritizing” a backlog to “ordering” a backlog, to ensure the product owner makes relevant decisions based on the entire backlog, rather than prioritising items against one another as pairs. Prioritization is thus just one way of ordering a backlog.
A ticket is an object – there is no emotional connection to a ticket, and there is no view of what is being delivered in the broader context. A ticket outlines what needs to be done and by whom, within a given operational level agreement (OLA) or service level agreement (SLA). This makes thinking task-based, rather than value-based.
Using the term “tickets” often corresponds with ticket-based thinking and a silo mentality. Using non-emotional terms, such as “tickets” creates robotic thinking, which leaves little room for innovation and disconnects one from the problems customers are facing.
What should we call “tickets”?
To correct the thinking, “tickets” should be termed such that the job can be personified and drive thinking towards the impact on the end customer, to ensure value is delivered.
The terminology is not set in stone and can vary across teams, depending on how the teams react to certain terminology, with no right or wrong term. What does matter is the terminology used must encourage value-based thinking e.g. asking questions during a daily stand-up such as “what endeavours have you been working on?” and “how does it affect the rest of the team’s endeavours?”. Terming it something as simple as “valuable task” can prompt team members to evaluate whether what they are doing is valuable for the end customer, as well as what other value could be added.
We should all be considering re-personifying our work and ensuring we are not merely completing tasks to move our “tickets” into the done column, but rather understanding the value we are adding at each step of the process and aligning our thinking to this.
Just as the best doctors don’t treat cases, but rather they treat patients with care, so we should care about everything we deliver to our end customers. Without this level of care, we have little vested interest in the value they receive from us.