What task am I going to work on next? I can’t seem to make any progress on this task anymore. Can I consider this task done? If you ever had thoughts like this, this blog post can help! Let’s talk about the process of a developer assuming a task and taking it to completion. Below is some advice that worked well for me and the teams I’ve worked with.
Choosing the next task
Keyword: Priority.
In our planning sessions, we should always consider the priority of our tasks or goals. We should determine beforehand as a team, which of those tasks are the most important to achieve. Sometimes, there may be unplanned tasks that come up in a sprint, like forgotten details or bugs. When determining the priority of these tasks, create a discussion within your team and prioritize against existing tasks accordingly.
This gives you a good idea about your team’s priorities, so the next most important task will always be at the top of the list. This ensures that even if the team misses some of their goals for the sprint, you are always incrementally shipping towards your MVP.
I’m stuck: Help!
There are several reasons why a developer can’t make progress on a task. It might be helpful to divide these reasons into two categories: internal and external. Internal blockers are when you are the one responsible for unblocking yourself while external blockers mean you need someone else’s help or input.
For example, internal blockers could be lack of knowledge, lack of experience, lack of confidence, too many things to juggle, or simply having a bad day. External blockers could be getting blocked by design, by business decisions, by another dependent task etc. Let’s talk about how to approach each of these separately.
Internal Blockers
The best way to approach any blocker is communication. If you lack the knowledge, experience or confidence to progress a task, communicate within your team that you are blocked, and ask to pair with someone or ask about it in writing. It’s easy to make the mistake of thinking this ‘someone’, should always be someone more senior than you. You can learn from anyone, and simply the fresh mind of another person could help you think about the right questions and gain confidence.
Similarly, if you have too many things to juggle or you are having a bad day, communicate this within your team, and maybe take a break, or just take it slow. Taking it slow, can mean instead of focusing on your tasks, you work towards unblocking others by providing reviews, feedback, helping by answering questions, pairing etc.
External Blockers
Is your task blocked waiting for review? Maybe you’ve sent the same friendly Slack nudge and brought it up in daily syncs, and still… no status change. It happens! While you’re waiting, consider asking another teammate to take a look, or shift focus to your next highest priority. As a last resort, if you have tested thoroughly and are sure of your changes, let your team know you’re planning to merge without a review. Communication is key!
Beware of having multiple tasks in review that are blocked in a similar fashion. This means you need to raise the review slowness issue in team retrospectives and try to find a general solution as a team.
Some external blockers, like waiting on another department or third party, can be outside your influence to help unblock. It’s important to let your team know that you are blocked, and raise it with stakeholders if needed. This allows the right people to follow up, and the team can work together on a strategy to mitigate. Again, if you must work on something else, keep it on everyone’s radar.
When to call a task “done”
Teams can have different definitions of “done” but generally, I think you can call a task done when you as the developer have no other responsibility toward it. This can mean either the task has already been shipped to users or you are not the one responsible for progressing the task further.
Whatever your team’s definition of ‘done’ may be, it is very important to start the next task after the previous one has been completed. This rule can’t always be upheld due to external blockers, so a better way to phrase this may be: Always prioritize your current ‘undone’ work over the next thing.
This is connected to the above point of ‘Choosing the next task’. Everyone in the team chooses tasks based on priority, and even if we miss some of the goals of the sprint, we still want to get the highest priority ones ‘done’. Jumping from one task to another task without completing any of them is bad for several reasons:
No value for users: You have multiple tasks in progress at the end of the sprint instead of one complete task. This means nothing gets shipped and no value is delivered to users.
Losing context: You lose context about the previous task. It gets more difficult to complete the first task even though it has higher priority. You also tire yourself by context-switching.
Hurting teamwork: When you are more than one developer in the team, you working on two tasks at the same time eliminates the opportunity for parallel work.
Final words
What this all means in practice is this: When you get stuck on a task due to internal blockers, instead of going for an ‘easy’ win, try to unblock yourself by following the above steps in order to complete your current task. But when you are externally blocked by things outside of your immediate control, communicate, then start the next task.
It is however, very important to remember that your priority remains the previous task. If the original task becomes unblocked, switch priority: return to and complete the original task whenever possible.
Don’t work on tasks because they are easy, work on them because they are the highest priority and the team needs that to be shipped next.
Get help from your teammates, which may look like a 1-2 hour pairing session to unblock you. Afterwards, your teammates can work on other tasks in parallel.
All these suggestions serve one purpose: get your team to success in the most efficient way. The art of product development is challenging and we learn something new about people and processes each day. These tips about the development process are based on my personal experience and I hope you can also take advantage of them. Don’t forget you’re always able to improve and adapt techniques based on you and your team’s individual needs.
