Choosing what to work on
Modern agile practices in software development are usually a synonym with well-defined chunks of work over a specific timeline, usually a 2-week sprint. What this implies is that by having a fixed timeline to work on, it also limits the amount of work that a team can deliver in that fixed period of time. So, it becomes imperative that people work on what can deliver the most impact. However, knowing how to choose exactly what to work on can be a bit of a tricky question that can arise when using these types of practices. Immediately, several questions can arise such as:
-
will I work on the thing that delivers most value in the sprint?
-
will it be the most technically interesting thing?
-
the most urgent thing?
-
the less well-refined item that nobody wants to pick up?
All of these questions are very valid and useful to be able to answer, but, it’s not always easy, especially when you also need to be in sync with other team members who all want to work on their own things and, besides all this, there are still team/company goals and roadmap items to attend to, so, I believe that knowing (and choosing) what to work on becomes more of a balancing act between the aspects outlined above than simply following some pre-determined order of work. In an ideal scenario, these questions raised above can be covered within one single ticket which can be considered almost like a “golden nugget”: if you work on it, you are sure to learn a lot, deliver a lot of value and make stakeholders and other team members happy when the task that gets picked up is considered too hard or deviates too much from normal work.
I think finding these “golden nuggets” is a skill that can be practiced and learned and when honed over time can make you become a much better and well-rounded engineer. While the particulars will vary from company to company and team to team, I believe there are some key aspects that can be taken into consideration when choosing these so called “golden nugget” style tickets:
-
firstly, if the task falls out of the standard sprint work that you and the team normally do, it can be a good indicator: this can involve tickets where cross-team collaboration is needed, or working more on the infrastructure side of things, for example. Since these type of tasks usually are more ad-hoc and fall outside of normal work, it can be a good indicator that you might be looking at a golden nugget.
-
secondly, this is more of an empirical thing, but, very simply put, if there’s a ticket or epic that nobody wants to pick up for whatever reason, that can be your way in to find yourself working on a really interesting piece of your business and learning a lot, both technically and from a business perspective: it can an old ticket, or a ticket that requires a refactoring of a particularly gnarly piece of the codebase. No matter what, you are sure to learn something.
Obviously, your work must never consist only of these style of tickets, but, instead, it should be balanced between normal tickets and these golden ones. By balancing your work, you will not only be able to become more well-rounded, you will also be able to learn from your colleagues how they tackle this style of work and how to learn from their setbacks, and, you will hone your craft while doing the regular work, which, in turn, will make you better equiped to tackle the more special tickets that will constitute a big learning opportunity, preparing promotion material or simply grow as an engineer.
How do you choose what to work on?