Product Backlog

A Product Backlog should contain stories that the Product Owner cares about, in the sense that they add clear business value and can be ordered by him or her.

Developer Stories can be introduced by a team into their own Sprint Backlog, if they think such stories are necessary in order to help mitigate technical risk. The Development Team wholly own the Sprint Backlog and they have a responsibility to plan it in such a way that the agreed User Stories from the Product Backlog can in fact be delivered.

Note that Developer Stories are controversial. Some deny that they even exist, and argue that the technical risk should be managed by identifying tasks against User Stories instead.

You say that the PO wants tasks on the Product Backlog. If so, there's a problem. The PO should care about the User Stories that have been negotiated into a Sprint, not the tasks that developers have identified for their implementation. The tasks are the developer's business, not the PO's. The developers, and not the PO, determine task priority by identifying them and organizing them into their Sprint Backlog accordingly. These tasks are typically identified during Sprint Planning, and so it would be irregular for them to appear in a Product Backlog at all.

We keep a list of "Technical Wishlist Items" that the developers want to work on bug do not provide clear immediate value to the customer.

if the TWI becomes an impediment to a PBI commited to a sprint, we add it as a card to the sprint board. If not, we take care of them during "TWI Time". TWI time is about a 4 hr block the team sets aside every sprint for the developers to work off the technical wishlist items.

To further clarify. TWI's are not changes to the codebase. e.g. "Rewrite db component" isnt a valid TWI since it would be changing the product codebase.

Examples of TWI's would be:

"Setup a build server to do nightly builds"
"Setup a discussion forum so developers can have technical discussions"
"Figure out how to run automated tests faster"

Thanks for the replies.

We kind of had technical tasks but they were just picked up when we had time.

The reason the PO now wants them on the backlog as they are stories that aren't from the business but from the developers but they do deliver business value in a way (I know I have contradicted my first post). The developers have now received some additional data from a third party source which needs to be loaded into the system as this is what is being moved onto the PB. These stories don't change the functionality, just the results of a search may be more enhanced.

Does this sound like a PBI from the developers or should it be worded from a users point of view requesting more comprehensive search results?

> Does this sound like a PBI from the developers or should it be worded from
> a users point of view requesting more comprehensive search results?

Both, these are not mutually exclusive. There's nothing to stop developers from identifying potential business value and proposing stories to the Product Owner. The PO can take input from any number of sources and consider it for possible inclusion and prioritization in the Product Backlog.

If the stories you mention "deliver business value in a way" then they should be treated fully as User Stories, and not as Developer Stories. Business value should always be made as clear as possible, and reflected in the Acceptance Criteria as well as the User Story itself. The developers can then plan technical tasks around those stories if and when they are prioritized into a Sprint.

Ian,

So you would say, 'As a developer, I want to load additional data so that greater details can be given for search results' is a valid story for the PB?

No, that's a Developer Story, not a User Story. A User Story should be written from the perspective of an end user or other business level stakeholder, clearly showing the business value that will be provided.

You said that these stories "deliver business value in a way". That's what has to be concentrated upon. What role is going to benefit, and how?

Ian,

That is what I thought. Would I just rewrite that story from the user view or leave this as a developer story on the sprint backlog? i.e. As a user I want to have further enhanced search results so that I can have more detail.

The PO wants this as a PBI because the development team received this additional data not expecting it. The PO didn't want it in straight away but said it must be in sprint X so prioritized it so they could move it up as the time got closer.

It sounds like we need to understand the sprint backlog and this is something I am new to (this is our organisations first project working this way). If the sprint backlog is the list of tasks required for the current sprint, where do developers stories like this live when they are not part of the current sprint but will be in a future sprint?

> Would I just rewrite that story from the user view or leave
> this as a developer story on the sprint backlog?

You'd rewrite that story from the user view. You'd give it to the PO so he or she can consider it for inclusion in the Product Backlog.

> If the sprint backlog is the list of tasks required for the current
> sprint, where do developers stories like this live when they are
> not part of the current sprint but will be in a future sprint?

In the example you give, the story isn't a Developer Story. It's a User Story with apparent business value, and it just happened to be uncovered by the developers. The PO should be told about it and he or she can then decide whether or not to include it in the Product Backlog.

Thanks Ian, much appreciate your comments in helping me understand.

I have to agree with everything Ian has said. This sounds like a user story.

>These stories don't change the functionality, just the results of a search may be more enhanced.

If the results the user received is displayed differently or has additional data then you are changing functionality. How is the search result more "enhanced"? What additional pieces of data does the user receive in the search result? How is the presentation changed?

Possible user stories:

Data change example:
As a user performing a search for dogs, I would like for dog eye color to be included in the search results displayed so that I dont have to open a specific dog's profile to see the eye color.

Presentation change example:
As a user performing a search for dogs, I would like for the dog eye color field to be presented with a background color of the dog's eye color so that i can visually identify which eye colors are returns in the search results.

randyh, when I meant it doesn't change the functionality I meant the way the user interacts with the system.

Prior to the extra data, of the 60,000 records we had, only 27,000 had data within field X so for the other 33,000 it was blank. This story was to populate the other 33,000.

Just one last question I promise! Do developer stories on the sprint backlog got estimated in story point when it comes to planning?

> Prior to the extra data, of the 60,000 records we had, only 27,000 had data within field X so for the other 33,000 it was blank. This story was to populate the other 33,000.

That is still a user story and not a developer story.

Why does the field need to be populated? If the customer doesnt care about it being blank, why should the developers perform the work? Why would the PO want the developers to be spending their capacity on putting something in the field?

> Do developer stories on the sprint backlog got estimated in story point when it comes to planning?

If a developer story list is maintained separate from the product backlog. What value does giving an effort estimate provide? My team, for example, doesn't estimate our dev stories because the team prioritizes them and are able to judge what needs to be done first without an effort estimate.

randyh, completely agree that is a user story. The customers want that field to be complete all the time. Our project is a little tricky because we are just proving that we can generate results that match those done by someone else as a proof of concept before we decide if we can take it on permanently so to save wasting time, the customers were happy to take the data as is so they could at least start working with it.

As for the developer stories, I was just asking the question if it was estimated so they know how much work they can take into a sprint. If the user story point velocity for a sprint is 100 but they have a developer task, how is the velocity for the sprint worked out? We have been estimating these stories and including them as part of the velocity.

Psmith,
Yes, the product backlog contain developer stories, technical chores, knowledge acquisition, prototypes etc. Scrum is not specific about exactly what a pbi is or how it should be expressed. User stories are popular but that does not mean that all items must be expressed as user stories. Whoever put it on the backlog works with the po to determine the priority. I favor having this in the product backlog for transparency reasons. I would however not count these stories/chores/tasks when calculating velocity (if calculating velocity is important to you). This is stuff that you need to do in order to/faster build features with direct business value but they may not bring business value by themselves.