Creating and assigning tickets is part of the daily workflow for thousands of people out there. No matter what profession we are doing we need to collaborate with our colleagues in order to build something really useful and functional.
The workload for such projects needs to be divided into small and prioritized deliverables and then shared among the team members. This is not an optional procedure and definitely is not something we have to do only for big projects or teams.
Splitting the workload helps us to deliver and reach closer to our end-goal day by day.
So how do we split the work?
My experience with agile methodology taught me a bunch of new words and terms such as user stories, the definition of done, acceptance criteria, team’s velocity, cross-functional team, planning, refinement, review, retro, backlog grooming and so on.
All these definitely make sense and they do help us hugely to collaborate using some well-defined patterns and strategies and ship complex deliverables.
So what is all about?
I think we all tend to focus on those buzzwords or even the process itself but we miss the actual meaning behind all these. Stories should be created so that people who are going to implement them, can understand with a single read what needs to be done. It might sound utopic but this is the principle we all should follow while trying to write down a user story.
Why? In order to get things done while reducing the managerial overhead. No extra meetings, no calls, no catch-ups, no follow-up emails, no extra tickets to explain a ticket, no extra meetings to analyze a meeting. Nothing.
A story should be something really well-defined. If it is confusing then some details probably are missing. If it is rather complex then it should be divided into many smaller ones.
All these mean only one thing: this story is not mature enough to be assigned to the team yet 😬
Agile might confuse people
Unfortunately, people might misinterpret Agile. Since it is ok to have quite a few meetings and discussions about upcoming features and requests we may think it is ok to improve user stories and specs progressively throughout those meetings and the sprint itself.
This is a huge mistake because people get confused when they read incomplete requirements and then chaotic brainstorming starts. Sharing thoughts and ideas are highly welcomed but it is not that helpful when team members participate in long and pointless discussions without having the full scope in mind.
Such discussions mostly end without any actual outcome or decision and most participants tend to get frustrated because of this situation. They feel ineffective and all this is the result of some badly written specs.
Fire and Forget Missiles
Team leads should be aware of this pitfall, that’s why they should care first about their colleagues and invest in this relationship by trying to be as much helpful and explanatory as possible even throughout written communication.
When we write tickets with just a title using 4–5 words and then assign it to a team it’s like throwing a rock to their head. We simply push the responsibility away from us and this is poor management.
This reminds me of my days in the Navy and “fire and forget” missiles. These are missiles that don’t communicate with the launch platform after they get launched. In our case, the missile is the ticket and guess what. No-one has actual control over it. It is a “fire and forget” one.
One minute manager
Recently I read the One Minute Manager and it rang a bell. If we are not able to read and grasp a ticket in 1 minute then this ticket is not helpful at all. We probably need some clarifications or its scope is rather big so we need to go over and over again and again.
The bigger the ticket and the volume of the specs mentioned, the more probable it is to ask for some extra clarifications. It is highly possible that we will end up pinging the author to arrange a meeting and this is a never-ending loop that will cost us time and actual results.
Conclusion
Creating fine-grained stories and tasks is really hard and sometimes even more boring but it is vital if we want to help our teammates deliver awesome stuff. Treating tickets like “fire and forget missiles” is like shooting our team in the leg. Cheers!!
Marios Fakiolas
Full-stack JavaScript lover, happy husband, proud father 😉
Software Engineering Manager / Frontend Head at @omilialtd