Examining What Is Important To Work On In Software Projects

I observed this week several vectors acting on my thinking. It’s important to focus on the product and the overall mission, as I said last week. That’s the main vector. But then, you look at the active sprint, and you look at what else is left. Low priority tasks left there as low-hanging fruit. Second vector comes in – I want to work on something that is valuable to the team and organization, something that advances the main vector.

So, I look at the backlog and look at the bigger tasks, not prioritized in the current sprint. There are still tickets there, needed to get the release over the finish line. Bigger tasks like API integrations or outstanding features. So, then you weigh up the first two vectors. Something valuable, preferably not low-hanging fruit, and something that advances the product. By my own internal logic, picking up something from the backlog makes sense then.

And this is where internal logic is not not sound, but defies a third important vector team norms and culture. What does the team do? What is accepted in the team? And there, internal logic – even if sound – can come up short with team norms. In some teams, it’s acceptable and encouraged, on some level, to pick up tasks from the backlog. But in others, it’s not if it wasn’t included in the initial sprint planning and not added later during sprint refinement.

There is no actionable method on offer here. Thinking through things, as you navigate a new role and organization, will help you identify the important vectors at play and your own internal logic.

Verified by ExactMetrics