As a Project Manager on a complex IT project, your challenge is twofold: not only do you need to determine what needs to be accomplished in upcoming sprints, but you must also effectively communicate these tasks to developers so that they feel confident and committed when opening an issue in Jira.
In this post, I’ll share the simple, practical rules I’ve learned for assigning tasks to developers while upholding the core Scrum values: openness, respect, focus, courage, and commitment.
1. Selling the Big Picture
I don’t simply tell my team members what they should do because I’ve decided it. Instead, I support my rationale by thoroughly documenting the requirements in the issue ticket, using diagrams, schemes, or relevant sources.
I explain why the task is necessary and how it fits into the overall project.
For example:
– “Last week’s A/B tests revealed that this button animation improves user experience and increases click-through rates, which in turn will lead to higher conversions on our marketplace.”
Explaining the task’s origin from a requirement, product, or market perspective helps the team understand its importance and gives me an opportunity to demonstrate what I know—and what I don’t. This approach reflects the Scrum value of openness.
2. Crafting the Issue Description
Jira allows you to pre-fill issue descriptions, so I use a template tailored to the issue type. The template includes fields like user story description, acceptance criteria, non-functional requirements, test cases, out-of-scope items, and attachment descriptions. This pre-filled information helps eliminate assumptions and ambiguities.
I also ensure that dependencies and deadlines are clearly communicated:
– “This task must be completed by the end of the week because the launch of new functionality depends on it.”
Providing this level of detail before bringing a task to a grooming meeting is essential. It’s my way of showing respect for the team’s time and effort.
3. Using the Right Vocabulary
Striving for clarity, specificity, and simplicity in task descriptions is crucial for two reasons. First, technical jargon is already quite versatile—terms like “container,” “framework,” “class,” or “script” can have different meanings depending on the context. Second, issues may be reviewed by stakeholders who are not familiar with the context, such as other product managers. Clear documentation is also an asset for future projects.
To minimize ambiguity, I avoid qualitative, subjective terms like “beautiful design” or “optimize UI.” Instead, I use descriptive, measurable language, such as “increase size by 10%.”
4. Balancing Workloads and Resources
When evaluating the workload of a task, it’s important to ensure the right resources and tools are available. Workloads should be balanced among team members to prevent burnout. If I have a highly efficient developer and others who are less experienced, I prefer to have the senior developer coach their colleagues or try pair programming, rather than placing all the burden on one person.
5. Following Up as a Team Member, Not a Manager
Backing and supporting the team is key when assigning tasks. I stay engaged with how work on specific tasks is progressing and ask for feedback. This demonstrates commitment, one of the core Scrum values.
However, I’ve seen some “taskmaster” PMs resort to micro-management, leading developers to feel pressured to deliver anything just to get the PM off their back.
Some bad examples of phrases I’ve heard during meetings include:
-“Do it as quickly as possible” or – “It shouldn’t take long.”
These create a sense of urgency that can negatively impact work quality. Instead, I inform the team about task dependencies and external deadlines, trusting the developers to stay focused. When the team understands a task’s impact, focus—another Scrum value—naturally follows.
Similarly, I avoid phrases like:
-“It must work; we can’t afford to make mistakes.”
This kind of language implies that mistakes aren’t tolerated and can make developers feel insecure. Instead, I allocate time for testing before the demo and manage stakeholders’ expectations. Being factual and solution-oriented, rather than emotional, when asking for feedback yields better results.
6. Lift Your Head Up When Bogged Down
Sometimes, stepping back from the console can greatly benefit team performance. For example, during a project in the metal production industry, I organized a one-hour presentation on a Friday, complete with pizza, about interesting facts in metal production and how our work related to it. This meeting was a great success because it helped developers see their place in the industry and the impact of their work on the production site. Or maybe it was just the pizza.
Sebastian Zelechowski