Agile process models are quite popular, even if there is still much discussion about their applicability in any given case. I do not belive that Agile is a silver bullet, but I, personally, like working in an Agile environment.
Agile or not, work should be planned. Planning of work is performed very often using a ticketing system. In most of my assignments, this ticketing system has been Jira.
In Jira, I like to use the following types of tickets:
- Stories for the usual work that has a defined scope and takes an estimated amount of time (or, vice-versa, is precisely timeboxed and has an intention of achieving something)
- Sub-tasks if I need to structure the work somehow. I use this “layer” of tickets very infrequently.
- Epics as a series of Stories that are connected somehow (for example, a user-facing functionality that should be created with a couple of Stories)
- Bugs for unplanned work such as, well, bug analysis and fixing
Thus, the bulk of my work is performed within Story-type tickets. There was even an old reggae song “No Story, no work” or something like this. It is prudent to stop and think a little what is a good Story-type ticket. How much work should be specified within a Story?
This problem of granularity of the work ticket has a significant influence on the efficiency of work.
A ticket that is too big can lower the motivation of the developer(s) and thus diminish the productivity. Big estimations tend to be inaccurate – this is why Fibonacci series is often used for ticket sizes – and thus promote waste. Related to this, big tickets tend to have vague formulations, which promotes scope creep. If a big ticket has a precise formulation, for a change, then it will have many work items – each of them, apparently, not worth becoming a ticket on itself – which will just beg for somebody to add “just this one small task, it is closely related” – scope creep again.
Tickets of a too small size can lead to big problems also. For each ticket, there exists an overhead that does not scale. The productivity will suffer a direct hit – and will be further lowered by a low motivation of developers forced into useless (from their point of view), repetitive tasks.
So what is a good size for a Story to work on?
We want a ticket with a clear aim, some measurable improvement for somebody – be it a customer, or be it the dev team themselves. A ticket on which one person could work consistently on, remembering what he or she did at the start of the work when they approach that review of the Pull Request. But still the work at hand must not be trivial.
So we end up with something like a SMART guideline for the specification of work tickets.
Specific, we need to know what we want to achieve.
Measurable – this is the definition of done for the given ticket.
Attractive – the work should take some effort
Realistic – the work should be achievable
Timeboxed – even if we use some abstract complexity points, the given ticket should fit into one sprint. We do not want to plan for spillovers.
But what does this mean in practice?
Create work tickets that take anything between one full day to one work week, taking into account meetings and other distractions. The content of the tickets should encompass all: documentation, code and tests. It should contain writing the method signature in the interface and the implementation of this method. If this is too big, create stubs that will then be worked on in the next Story. A small and handy ticket that prepares a work for another ticket is better than a Story that tries to solve all problems.
As usual, these are more guidelines than strict rules.
(The opinion presented here is my private only and does not necessarily correspond to the one of my employer. But of course I am applying my experiences in my current role profitably.)
Leave a Reply