Agile teams sometimes struggle with the planning of pure technical tasks, like tasks that have to do with technical debt. Such tasks have no direct value for the user of a system, but have to be done to deliver working software. Should you create user stories to handle such technical tasks and technical debt, or not?
In the blog post "As a Developer…” Is Not a User Story, Bill Wake talks about user stories that he encountered which do not have value for the customer. As an example he mentions the user story "As a developer, I want to configure Jenkins so that we have continuous integration". Bill explains why he thinks we shouldn't call them user stories:
My argument is not that those activities are not good or important things to do (they are for this team), but that thinking of them as user stories misleads the team and its customers. Writing something in the form of a user story when it's not about users of the system misses the point.
His opinion is that we should call them tasks in stead of user stories. Applying lean thinking, he considers them to be waste:
From that perspective [of lean thinking], many of the activities teams do can be regarded as a type of waste, but we don't know how to develop software effectively without doing them. Lean teams talk about this kind of waste as "Non-Value-Added But Necessary": work we do because we have to.
Bill suggests to be critical on user stories where the role is somebody from development, in stead of an actual user of the software. Try to reframe such a user stories as functional behavior or quality characteristic and rephrase it, if that isn't possible then consider it to be a task. Task are there for the development team to track, but should not be put on the backlog as user stories since they are not delivering value:
(…) recognize that your team will sometimes just have tasks. You may decide to track tasks internally, but don't treat them or track them as direct progress on the developed system.
Mattias Marschall provides a solution on how to handle technical tasks in a backlog, in the blog post how to translate “business value” of things that are technically important. He starts by explaining how he sees the relationship between user stories and technical tasks:
User Stories should describe what a user wants the system to do. Purely technical tasks should usually be implemented as part of a User Story.
But what about technical tasks which are not directly related to a specific user story? Mattias suggest to put them on the product backlog:
To be able to put technical tasks into the product backlog for prioritization, just create a User Story for each of them. But, isn’t that cheating? Not if you can answer these two questions:
- Who benefits from the result?
- Why is this task necessary?
With his solution you can have all the technical tasks covered by user stories in the backlog, either as a part of a user story for a customer, or with a user story specifically for the technical tasks:
If you’re able to formulate your technical tasks as a kind of User Story, your stake holders will be able to understand the necessity of them and will be able to prioritize them along with other User Stories.
Bastian Buch explains in his blog post effective steps to reduce technical debt: an agile approach that developers and product owner can have a different opinion on technical tasks that are related to technical debt:
Developers know about technical debt and are aware that it is important to face this problem.
Product Owner often doesn’t understand the need and benefits of reducing technical debt and don’t consider or allow technical projects / stories in their backlog and release plan.
He suggests that the product owner should take responsibility for reducing technical debt. Team members should discuss technical debt with the product owner, and work together to give it the right priority on the product backlog:
The team should remember the product owner that he is part of the team: his pain is the pain of the team and other way round. He is not the customer, payer or employer of the team but more a SME (subject matter expert) and manager / analyst of product requirements from different stakeholders.
As a team give your product owner the guarantee that growth of the product will stay the most important part – but not just in a short team (Performance) but also in a long term (Health) manner.
Bastian proposes that we should collect the technical problems into user stories, estimate the effort needed to solve it and the benefits that solving would bring. He calls the benefits “payment”, as solving the problem reduces the technical debt:
(…) we created stories marked as “TechnicalDebtItems” in JIRA for each task we defined. For bringing those items into a prioritized order and for drawing the right conclusions, we created a chart to visualize how the efforts relate to the payment and vise versa.
Making things visible helps the product owner and the team to collaboratively reduce technical debt.
[With] the visualization of the debt and the finding of a possible repayment plan (…) the team now can focus on the most important steps. An important side effect: This overview is also a great tool for working with the product owner and other stakeholders because it gives him a good transparency regarding technical debt.
Community comments
Works only if you have a super PO
by Eric Zimmerman,
Re: Works only if you have a super PO
by Mike DePaoli,
Re: Works only if you have a super PO
by Ben Linders,
Re: Works only if you have a super PO
by Mik Quinlan,
Re: Works only if you have a super PO
by Mik Quinlan,
Here there be dragons
by Mark Levison,
Re: Here there be dragons
by Charles Bradley, Scrum Trainer...,
Re: Here there be dragons
by Mike DePaoli,
Re: Here there be dragons
by Mark Levison,
Re: Here there be dragons
by Charles Bradley, Scrum Trainer...,
Re: Here there be dragons
by Mark Levison,
Story vs. Task regarding Refactoring.
by K. Ramesh Babu,
Story vs. Task regarding Refactoring.
by K. Ramesh Babu,
Story vs. Task regarding Refactoring.
by K. Ramesh Babu,
Story vs. Task regarding Refactoring.
by K. Ramesh Babu,
Where is the architect?
by Alfredo Cerrillo,
Works only if you have a super PO
by Eric Zimmerman,
Your message is awaiting moderation. Thank you for participating in the discussion.
Having a product owner who also own the technical side and is able to properly prioritize technical work along side functional work in the back log is almost never possible. At least i've never seen it. But i'd certainly like to hear success stories here. You'd really have to have a "super product owner" one who really understands modern software engineering practices, and who are able to differentiate waste from valuable "technical" user stories. Further the developers would really have to trust that the super PO really understands their world. If you don't have a super product owner, you really are going to have to build a trust relationship between the developers and the product owner, where they all believe they are working to the same goal.
Most of the time when I see the product owners also owning technical decisions, there is a significant and long standing trust problem on the team between the PO and the developers, and that is what needs to be solved by in part educating the team about roles of team members, and the reason why technical best practices are important to the team as a whole in the long run. But rebuilding that trust can be very difficult.
Here there be dragons
by Mark Levison,
Your message is awaiting moderation. Thank you for participating in the discussion.
Imagine the following conversation:
Team Member: "PO Jane, we need to rework the underpinnings of the foobar class so that we can work faster"
Jane: "Team member, why is that important?"
Team Member: "Jane - its slowing us down. Every time we go and work in foobar we spend a extra 20 minutes a time just trying understand the mess that is there. If you write a User Story and give us 5 days it will all be perfect"
Jane: "Team Member, can I trust you? Will this be the last time I ever hear about the foobar class?"
....
As we can see there are several problems at play here:
- We're expecting the PO who is business domain expert to make technical decisions.
- Team members are making promises they can't guarantee: Give me 5 days and foobar will be better once and for all
- User Stories are intended to be focused on real users
- It pretends this work has real value. We're doing it because we weren't really done in the first place.
Instead of bamboozling the Product Owner I find it more effective just to pay an ongoing tax in the range of 15-40% (depending on the state of the code base) and then maintain a separate list of technical impediments. This issues are best only addressed when the team is already working in that part of the code or the issues are causing problems elsewhere.
If for some reason you really really think you must have it on the main product backlog (for reasons I can't see) then don't bother writing a User Story. Not everything in the Product Backlog needs to be or wants to be a User Story.
Re: Here there be dragons
by Charles Bradley, Scrum Trainer...,
Your message is awaiting moderation. Thank you for participating in the discussion.
+1 to Mark's comments -- totally agree.
My strategy for this kind of thing, in line with Mark's "ongoing tax" idea is described here:
"The Development Team Improvement Backlog"
www.scrumcrazy.com/Scrum+Strategy+-+The+Dev+Tea...
Re: Works only if you have a super PO
by Mike DePaoli,
Your message is awaiting moderation. Thank you for participating in the discussion.
IMO, you don't need a super-PO, you need a good leader. A good leader can choose trusted advisors that can put things in terms they can understand and then weigh the alternatives and make good over all decisions.
I advise POs, especially complex domains, to form a 'POAG', a Product Owner Advisory Group. It is made up of SMEs both technical and other involved in delivering value to the customer, including representation from the dev team. It is usually a small group 3-5, but not always. For example, I've worked with teams that build medical imagine devices. There is a broad number of fields involved in this endeavor and one person couldn't know everything.
Having a group of advisors regularly engaged (ex. backlog grooming) allows for emergent design and last responsible moment decision making. Otherwise there is much greater pressure to have much more big upfront design. Most good POs do this informally in some form or another anyway. By making it a little more formal the PO clarifies roles, streamlines communication and visibly shows broader consideration of interests which aids in building trust.
A PO having a POAG, especially in this type of domain, IMO, shows good judgment and leadership qualities.
Re: Here there be dragons
by Mike DePaoli,
Your message is awaiting moderation. Thank you for participating in the discussion.
Make ALL WORK VISIBLE is one of the foundational tenants of Kanban. This includes the work necessary to deliver the value desired by the customer given an organizations current capabilities. Yes there may be significant waste, but if we can see it we can start to do something about it.
I find too many instances where folks, when learning agile requirements management get caught up with the religion of whether something is a User Story or not and miss making visible work that currently needs to get done. Don't get me wrong, I agree with Bill Wake's classification of what a User Story is and what is waste but it is just that a classification. It is more important at first for folks to see all the work then worry about its appropriate classification. If you've got a good color coded system for your physical release, story and or task boards, re-classifying isn't that hard. If you're using a decent ALM tool, it's easy.
Visibility of all the work is also essential for effective dependency and issue management in planning. Just because something is classified as waste doesn't mean you won't have to do it given your current state. Maintaining separate lists can often make this visibility more difficult and make it more difficult to enforce the idea of levying a tax. If things are presented in relational context, it is easier to explain 'if we don't do this, you can't have that'. (BTW, I think the tax concept is a good one and have seen it work effectively)
Lastly, a focus on technical excellence (which includes quality) is in the Agile Manifesto for a reason. It is professionally and fiscally irresponsible to not focus on these and shows an a short term and short sighted perspective and the cost of the future. Recent economic catastrophe in the housing sector should be a good reminder of the risks of short sighted thinking at scale.
Re: Here there be dragons
by Mark Levison,
Your message is awaiting moderation. Thank you for participating in the discussion.
Mike - we agree keep all the work visible. Were we using a Kanban board I would suggest the team keep a separate list and swim lane for technical issues. I just don't see how we can reasonably expect a business/customer focused person such as a product owner can prioritize technical work.
Cheers
Mark
Re: Here there be dragons
by Mark Levison,
Your message is awaiting moderation. Thank you for participating in the discussion.
I had so much fun with this that I wrote it up as its own post: agilepainrelief.com/notesfromatooluser/2013/03/...
Re: Here there be dragons
by Charles Bradley, Scrum Trainer...,
Your message is awaiting moderation. Thank you for participating in the discussion.
Mike,
> get caught up with the religion of whether something is a User Story or not and miss making visible work that currently needs to get done.
This is not religion, it's maximizing user/business value. There is usually no end user value in resolving Technical Debt, nor is there end user value in "Technical Stories". The distinction is an important one, don't you think?
Also, not all work needs to get done. Only the most valuable work for the next cycle(sprint or cadence, whatever) needs to get done. Everything else is just guessing about future needs.
Re: Works only if you have a super PO
by Mik Quinlan,
Your message is awaiting moderation. Thank you for participating in the discussion.
Hi Eric
We do that very successfully where I am now (Shopzilla).
We just re-platformed our Inventory system.
The key is to have a strong PO and a strong Tech Lead, each with an appreciation of the other and trust as you said.
In fact, I have found that following the basic template of
As a <ROLE>, I want to <business / technical function> so that I can <business value>.
I have found using the company as the role brings us back to why we're doing some technical work - for the good of the business.
So taking the CI example in the article, we could have:
As MyCompany.com, I want to set up Continuous Integration so I can help reduce the number of bugs that are found in production.
I would probably re-write it to be something like:
As MyCompany.com, I want to ensure my software meets quality standards so that I can reduce the number of bugs found in production.
</business></business></role>
Re: Works only if you have a super PO
by Mik Quinlan,
Your message is awaiting moderation. Thank you for participating in the discussion.
LOL. Great autocomplete of tags, InfoQ! :-)
Re: Works only if you have a super PO
by Ben Linders,
Your message is awaiting moderation. Thank you for participating in the discussion.
I like the idea of a product owner advisary group. I have worked with organization who used product manager teams, with strategic and operational product managers. One of the managers was the PO for the team. Another organization had an PO teams, which was both a scrum team that filled a product backlog, and a scrum of scrum of the PO. The benefits of agile teams can also be Sollied to teams of POs.
Story vs. Task regarding Refactoring.
by K. Ramesh Babu,
Your message is awaiting moderation. Thank you for participating in the discussion.
If the refactoring involves an altered end user experience, even if slightly, I'd say it should be modeled as a story.
Story vs. Task regarding Refactoring.
by K. Ramesh Babu,
Your message is awaiting moderation. Thank you for participating in the discussion.
If the refactoring involves an altered end user experience, even if slightly, I'd say it should be modeled as a story.
Story vs. Task regarding Refactoring.
by K. Ramesh Babu,
Your message is awaiting moderation. Thank you for participating in the discussion.
If the refactoring involves an altered end user experience, even if slightly, I'd say it should be modeled as a story.
Story vs. Task regarding Refactoring.
by K. Ramesh Babu,
Your message is awaiting moderation. Thank you for participating in the discussion.
If the refactoring involves an altered end user experience, even if slightly, I'd say it should be modeled as a story.
Where is the architect?
by Alfredo Cerrillo,
Your message is awaiting moderation. Thank you for participating in the discussion.
As well as a Product Owner, with authority enough to define user stories, you need a Technical Owner capable to define technical stories. Otherwise every developer can define this kind of work, frecuently in contradiction with each other. Without a single technical authority, the PO has no option but decide in topics that he doesn't understand well.