Product Backlog Items VS Technical Tasks
Hi everyone!
While working with a Scrum Team over the past couple of months, I’ve encountered a surprising situation — the team doesn’t really use Product Backlog Items. I know it may sound strange, but here’s what’s happening:
- The Product Owner shares high-level product goals for the upcoming months;
- The Development Team breaks those goals down into technical tasks (e.g., “implement API endpoint,” “form layout,” “write tests,” etc.);
- The entire Product Backlog consists of these technical tasks;
- Sprints are planned and executed based on these technical tasks;
- At the end of most Sprints, the team doesn’t produce a usable or valuable Increment — just pieces of functionality.
In practice, the team is just “doing work” — but not delivering a potentially releasable Increment. The Product Backlog becomes more of a technical to-do list rather than a tool for managing value. As a result, we’re lacking transparency and fast feedback.
I feel that something is off, but I’m unsure how to best help the team shift their approach.
How would you explain the difference between PBIs and technical tasks to a team that’s used to this pattern?
How can we help such a team start focusing on delivering value instead of just completing technical work?
Have you faced something similar in your teams?
I’d really appreciate your experiences and advice!
You're right to sense something is off. What you’re seeing is a team focused on tasks instead of business value. The entire point of Scrum is not to do Scrum, but to deliver business value,
Product Backlog Items (PBIs) should describe valuable outcomes connected to a Product Goal. Technical tasks like "add fields to database", "update form", or "create unit tests" are how we get there, but they aren’t what the user needs. The technical tasks are usually part of the Sprint Backlog owned by the Developers, and also include a Sprint Goal and selected PBIs.
Try encouraging the Product Owner (accountable for the Product Backlog and Product Goal) and team to write PBIs from a user or customer perspective. I often see a user story format ("As a type of user...I want to...so that...") help. Then during Sprint Planning, let the Developers break those PBIs, described in the user story forma, into technical tasks.
Also, ask after each Sprint: "Did we create a usable, valuable Increment?". If not, the team is likely working in slices of horizontal technology components, not vertical slices of value. Helping them connect work to outcomes and goals is key.
Intrinsic motivation has been proven to be higher when autonomy, mastery, and purpose are in place, as described by Dank Pink in his book Drive.
Hope this helps.
Put the Product Backlog to one side for the moment. Each Sprint is a learning experiment, and right now there are missed innovation opportunities.
Do the Developers have a Definition of Done which assures that any work they produce will be of immediate usable quality? In other words, regardless of the state of the Product Backlog, can they conduct validated learning experiments at all?
I agree with @Chris and @Ian. They both have some great information and advice. But I'm going to share with you an experience I had that was almost identical to yours. My experience involved stakeholders, something that you did not mention at all. Maybe that is the part you are missing.
The team worked really well together. The Product Owner was the one responsible for the product, the Developers owned the work to build it. In this team, I worked as a Developer doing Quality Assurance. We didn't have a dedicated Scrum Master so I filled the role as much as possible.
The Product Backlog contained items that described what was needed to make the Product viable and to improve the customers' ability to use it. During discussions between the Developers and Product Owner, the Developers would add tasks to the item to help them understand/remember what needed to be done. At first, the Product Backlog Item would be pulled into the Sprint and all the associated tasks would be done. So we were building usable, valuable increments that were being shown to stakeholders and most often released to production in each 2 week Sprint.
Then one of the Developers left the company and we got a new "lead developer" on the team. When that happened the "lead" decided that it would be better to pull individual tasks from various Product Backlog Items into the Sprint so that a developer could focus on specific areas of code. They felt it would lead to cleaner code and better use the developer's time. As the person fulfilling the Scrum Master role I voiced my concern about the ability to deliver things in a timely manner and the rest of the team decided that it was worth doing anyway.
Fast forward 6 weeks. The team had not released a single thing to production and the stakeholders did not understand anything that was being shown to the them. In the Retrospective I brought this up to the team. The "lead" stated that this was normal for software development because the "stakeholders weren't technical and would not understand". To their surprise, all of the other Developers sided with me. They all agreed that if there was nothing built that the stakeholders understood then there was no value being created. They voiced their concern that the stakeholders could not provide any feedback to help the team adapt their work in a manner that would give the stakeholders what they wanted and needed. They all wanted to go back to the way they used to work. I proposed that the team experiment with the old way again. The "lead" was not happy but they were outnumbered and said they would "go along with this for a little while until the team realized it was wrong".
Fast forward another 6 weeks. The team was releasing multiple increments per Sprint. The stakeholders were happy and providing a lot of usable feedback. The developers were more involved and engaged in the work they did. Even the "lead" had started to show signs of liking the new way.
Maybe you can find a way to get your team to "experiment" with something different and see if they can find a way to deliver more frequently in order to get stakeholder feedback.
Thanks a lot, Chris, Ian, and Daniel — really appreciate you taking the time to share your thoughts and especially your real-life stories!
I'm also thinking in the same direction: encouraging the Product Owner, involving stakeholders more, and asking ourselves — is what we’re building really usable and valuable right now?
One thing I’d add from my side: in my case, it feels like practices were adopted faster than the mindset. So now I’m planning to invest more energy into helping the team catch up on the Agile mindset!