Should you put all work on the product backlog?
In a particular project I was involved in the stakeholders and the product owner was not interested in the technical tasks the team was working on. Technical tasks could be anything from setting up environments to software architecture work. The stakeholders were only interested in the user stories the team was working on and the progress in terms of completed user stories. The product owner actually told the team to stop putting technical tasks on the backlog because they could not relate to them and therefore could not assess their value or even prioritize them. Of course you write as much of the technical work in terms of a user story. But there are always technical tasks you need to do that are e.g. needed for multiple user stories.
So in the end the team satisfied the product owner and ended up with a product backlog with just user stories!
So where do you put all this technical work?
First of all, the team estimated the user stories without any assumption that any other stories or any technical tasks are already done. This approach improves user story independence and provides the product owner with the greatest flexibility on prioritizing the backlog. Because there were only user stories on the product backlog it also helped the team focus on developing only that part of the software architecture they actually need in order to realize the user stories at hand. It acts as a natural guidance for the team in applying the principle of Simple Design and YAGNI. So the technical work gets divided over the user stories and emerges as tasks on the sprint backlog only when and to the extend that they are really needed.
You might think that the big downside to this approach is that it hides work and does not provide the most transparency. I would argue that because architectural tasks pop up in the sprint backlog you are being transparent to the people who are interested in technical tasks, without confusing the ones who are not.
As a result of all this the team’s velocity is lower in early sprints and increases and eventually stabilizes over time because it benefits of the architectural work already done. It’s obvious that your velocity will increase once you have stable software architecture because you have to do less work.So it’s probably the case that stable software architecture gives you higher velocity. The interesting question is ‘how much upfront architecture do you need?’
This experience showed me the being transparent as a team is very important but in order to be so you don’t need to write ‘all’ your work on the product backlog.