Technical tasks of the tech lead of a dev team in the product backlog: yes or no?

Are you sure that a Scrum Team has a “technical lead”? What does the Scrum Guide say about team roles, and about the kind of work which should go on the Product Backlog?

Hello Ian,

In the Scrum guide: "The Product Backlog is an ordered list of everything that is known to be needed in the product".

In our Scrum team the tech lead belongs to the dev team and  I know that he should be considered as a developer.

For me the answer to my question is yes, but i would like to be sure.

Does the Product Owner think that these technical tasks you refer to belong in the Product Backlog? Does he or she value them and wish to order them in relation to other work?

Perhaps the Development Team really just need to ensure that Product Backlog items are estimated so as to take this technical work into account.

I'm curious, what would be the examples of tasks your lead should achieve.

On a different topic, what happened the day he's ran over by a bus, how will it impact the team? Will the team loose one of its members, with an impact to its cross-functionality, or will they loose everything and will be unable to proceed. What I am getting at, how much of the organizational structure is bleeding into your team composition?

what happened the day he's ran over by a bus?

Alex,

Just an FYI, but I find it is nicer (and easier) to frame such an argument around nicer terms than negative ones.   What if the team member is out on PTO, or decides to leave the company, or wins the lottery?

I have seen Dev team insert their own " systems stories" in the sprint log  to accomplish a specific user stories..  

An example would be  "Create a TransferObject to hold the xml message".  

The PO does not need to know how the feature is put together.. All he knows that a feature is needed and the acceptance crieteria.

We use JIRA to ensure that all items of the PRODUCT has some artifact /story. 

TO answer the question.. PRODUCT BACKLOG  can have Systems stories if they have been identified to support a specific feature on the sprint cycles.  This can and should be negotiated between PO and DEV team on wither its needed on PB or SB.

Hi to all,

Thank you for your input.

In fact, he PO wants to have a clear vision of the dev team velocity' .

So, to avoid hidden work he wants to have in the PB, all the tasks related to the work around the user stories.

@Alex

I'm curious, what would be the examples of tasks your lead should achieve.

Examples: monitor a platform, optimize request, create logs, etc.

So, to avoid hidden work he wants to have in the PB, all the tasks related to the work around the user stories.

Why does he need to see Development Team tasks on the Product Backlog, and not just Product Backlog items with estimates for completing the work?

@Timothy Baffa, neither PTO nor leaving the company creates a burning platform, or in Kotter's words sense of urgency. While the latter gets rather closer. You are right about winning the lottery, but every time I visit London it reminds me of how much more probable my version is than the lottery thing.

@Marie-Hortense I think there's a bit of terminology mix here. When I hear technical tasks to achieve stories, I hear "horizontal slice of work", "not demoable", etc. In my mind, product backlog is speaking to the product, to customer value. While grooming the backlog team should feel free to design and estimate stories in the way that it includes all the tangential work that needs to be done to get stories done. On the other hand, "monitor the platform", as an example you gave, is not really a task that supports a story. You can write a full-fledged INVEST story and associate value with that, can you not? Something along the lines, "As a support analyst I want to be notified of any system abnormal behavior so that I can react accordingly". That's your story to start, and it should be put through the usual cycle.

Hi Marie,

There can be for example spikes, refactors, enablers in the product backlog not the technical tasks. Achieving a sprint goal, development team divides its work into tasks, in order to come to a common alignment among them. Why the product owner needs to have visibility of those tasks? I feel it's too much micro-management. The velocity should be derived from the number of PBI's a team has delivered. Not the tasks. Do let us know, if tasks mean something else in your context. Thanks.

@Alex

When I hear technical tasks to achieve stories, I hear "horizontal slice of work", "not demoable"

Yes, I spoke about the "technical" work not visible by the customer but necessary for the implementation of an user story.

On the other hand, "monitor the platform", as an example you gave, is not really a task that supports a story.

Ok, I understand.

You can write a full-fledged INVEST story and associate value with that, can you not? Something along the lines, "As a support analyst I want to be notified of any system abnormal behavior so that I can react accordingly". That's your story to start, and it should be put through the usual cycle.

Thank you for this example.

Hi Beenish,

We have already spike as an issue type in JIRA.

The velocity should be derived from the number of PBI's a team has delivered. Not the tasks. Do let us know, if tasks mean something else in your context. Thanks.

In fact in my mind, I thought that as the tech lead is a member of the dev team, his work must also be logged in the PB and estimate.

Seeing all the answers:

1) I'm not right in my vision

2) a "technical" need can be an user story.

@Ian,

Why does he need to see Development Team tasks on the Product Backlog, and not just Product Backlog items with estimates for completing the work?

As the dev team is offshore, the PO wants to know as exactly as possible its work.

As the dev team is offshore, the PO wants to know as exactly as possible its work.

Based on your reading of the Scrum Guide, do you think that is a good reason for a Product Owner to try and incorporate a Development Team’s technical tasks into the Product Backlog?

Shouldn’t those tasks be identified by the Development Team during Sprint Planning, and incorporated into a Sprint Backlog which is their forecast of work for that Sprint?

Yes, I spoke about the "technical" work not visible by the customer but necessary for the implementation of an user story.

Therefore, IMHO this work can be safely incorporated into the relevant user story estimation. If this reduces granularity of work, then the dev team can split the story into individual tasks the PO does not really have to know - as long as the user story in total can be delivered within the sprint.

I think, a development team can have a member, who has a skill or the area of focus "technical lead". This team member can ask or convince the PO to include technical PBIs to the product backlog. This is ok and not always the result of an unsatisfied definition of done. Software frameworks do change over time, get deprecated etc. It is up to PO to accept and priorise this PBIs.

@Artjom

This team member can ask or convince the PO to include technical PBIs to the product backlog. 

After a team discussion, the PO decided to include them in the PB.