Split the damn tickets

Hey there, I want you to start reading and after reading, to start splitting!

Sharing with you the way how we are handling our client requests and issues, so we don’t get lost, don’t forget anything and DELIVER things in time.

The first thing I introduced to the company was — Splitting the large tickets and obligatory estimations for all the tasks.

Why? We were only 8 people team, and most of the engineers are really self-organized and have advanced development level, so there were no troubles with issue delivery.

However, the time logged in the issues looked like this:

Someone has worked for 5+ days with one task and it’s delivered in the end. So what’s the problem with that?

Possible problems that you will face without issue splitting:

1. Only the person who is assigned to the task knows what done, until the task is completed. So, you as a Project Manager have to wait for 50 hours to actually see if everything is according to plan (SPOILER: it won’t be).
2. Developer might be stuck in some small part of a task, that is blocked by something that is out of his competence (Server configuration, Back-end issue, lack of some accesses, info, etc). You will have to stop working on the task and figure out what to do (and how to separate what is already done).
3. You can always check the time logs or comments on GitHub and track what actually was made. In reality — it’s not working:

Therefore it was my first priority was to make task progression visible to everyone, not just the developer who’s task it is.

Moreover, it serves other very crucial purposes for businesses:

More precise estimates

Usually, it’s done by the team and project manager/scrum master in a meeting called Sprint planning. The idea behind such a meeting is to have all issues for upcoming sprint (1–2 weeks, as the team decides) discussed, so they have a clear understanding of what needs to be done and all concerns / missing information is discussed and provided, before the tasks can be put into the sprint.

By breaking the issue into smaller ones you carefully think of an issue, what parts are there. What functionality we can isolate and create a separate ticket from that.

Of course, you will face a situation when a task is not splittable into smaller pieces than 2 days work and my colleagues promised to spam hundreds of examples of such cases if I haven’t included this remark into the post.

Instant feedback on task impediments

Whenever your backlog is split into small tasks, you can always have a hand on a pulse and see the impediments faster. People got used to doing everything at the last moment and they feel relaxed with big estimates on the task, which is good. Let’s say you have an issue for 1 week, on Monday you think that you have TONS of time because it’s only Monday and you have already achieved so much, so on Tuesday you work more relaxed, pay less attention to the delivery schedule. Same happens on Wednesday. On the 4th day, you realise that task is not even close to done, you start to stress out and feel depressed, because time runs out and you haven’t completed the ticket entirely. Also, you have no clue, why this task was estimated for a week and not for two!

Less lag for business needs

Ever faced a situation, when your client requires some immediate action from your side (let’s say critical bug on production or some very urgent change, that’s needed by business)? It happens a lot! With smaller tasks, you can free up a developer at predicted time (2–8 hours range) without affecting current task. Or you can put current task on hold and take critical one. With smaller task put on hold, it’s easier to get back to it and continue work, you will not need to remember a lot what have been done.

Optimistic estimates

We work in IT, and most of the IT guys/girls are very optimistic with their estimates. Very often developers think of a final solution, that the road will be clean and clear. “I will write that line of code and it will solve everything”— how many times we thought like this?

Unfortunately, in most of the cases, it’s not true. Even the slightest and most straightforward change can have some huge impediment or hidden complication inside, with dependencies, requirements change, compatibilities or some code that was written before you…

The same happens with estimates — we are being optimistic about tasks we need to complete. Usually, there is some % of error and the harder the task, the bigger % of error it creates. With that in mind, smaller tasks have less error % added to the task (working with the same team, based on Estimate / Actual spent time you can tell approximate individual % of error for each developer), so your team is more correct with estimates and delivery.

It makes you happier

Completing the task makes you… happier!

By completing, you can see the delivered value, you feel needed and encouraged by the end of a day seeing how many useful and billable work you’ve made.

Little by little you are chipping through the backlog and you won’t notice that most of your HUGE tasks are gone and done.

Making a habit

By delivering small tasks from day to day creates a habit for you, to get at least one “DONE” thing a day. That has a great impact on your personal development, also for a business overall, because… you can actually PLAN things in advance, because you know the velocity of yourself, your team.

Summing up

By introducing such a small thing to your team or company, you will gain control over your delivery, developers and PM will see the progress and team will have a more healthy backlog.

You will be able to plan your future work, review and actually see what is DONE and what is blocked on the way. It will give you a faster way to react on impediments and solve it before it’s costing too much. And become more happy with work!

Stay tuned for the upcoming PM topics!

Receive a new Mobile development related stories first. — Hit that follow button

Twitter: @ChiliLabs

www.chililabs.io