How to handle non-development tasks

How does the self-managing team wish to handle this...and why are management deciding what work they ought to make visible on their board?

Since you're using Jira, I'll give you a tool-specific answer.

It's totally OK to keep track of this information in the same Jira project using issues. In fact, it's what I'd recommend. However, I'd use either a specific non-developmental issue type or a label so that way the board/backlog view used by the Development Team wouldn't have these on them. A separate board/backlog can be used to give the right people visibility into either just these issues or the overall state of the effort.

You can use the Jira roadmapping tools with Epics and these other issue types to see alignment between these tasks and the work being done by development teams. This visibility and the ability to link the work items together to see dependencies will help stakeholders make informed decisions.

I agree with @Ian Mitchell's questions.   

I also agree with @Thomas Owens' suggestion.  There are ways in JIRA for the Development Team to maintain their Sprint Board with items while other items show up on a separate board.  But something you said makes me wonder.

So, basically these are tasks that the team needs to do in order for a successful project, but not necessarily critical for the product itself. 

If the Scrum Team is responsible for the work and it is directly related to the Product, why wouldn't it be included in the Product Backlog?  If the Development Team is involved in those activities, it should also be included on Sprint Backlogs. And I would argue that without success of projects the product is not going to be successful either.  Implementing a new feature in the code base but not setting up the users for success in using it doesn't seem like a successful product strategy.

- Communication topics: prepare timeline on when to inform employees, etc

- Training: prepare the material, schedule the trainings and give them

Could this work be part of a continuous workflow, rather than split out to separate tasks?

If so, it might make sense to include sentences like "Communication for the Increment is planned" and "New or changed functionality is supported by sufficient training materials", in the definition of "Done", and then the Development Team may potentially represent stages on their workflow for ensuring this work is complete for each Product Backlog Item before marking that item as "Done".

This would probably need to be supported by a more structured, ongoing way of sharing this knowledge.

Perhaps it's sufficient to communicate at the Sprint Review, and back that up by providing access to a living document of the latest changes. Or send an email after each sprint, and highlight the most recent changes on that document.

As for training materials, it may be that the best way is to make the product more intuitive, which is why I proposed that wording for the definition of "Done". Perhaps over time, the focus should be on providing a more natural user experience, such that the amount of required training is minimized.

Where training is required, perhaps the best way would be to provide a help page, maybe with videos, or provide guidance through an in-product walkthrough. This can then be used to make training more self-service and on-demand.

If there is a need to have actual training sessions, then maybe they should be scheduled on a regular rhythm (e.g. a few days after the end of each sprint), and the Development Team would simply update those training materials with each "Done" item, so that the trainer is always able to prepare for each session, using the latest product Increment.

[1] I agree with @Ian Mitchell's questions. --> Because it is not related directly to product vision.   

[2] I also agree with @Thomas Owens' suggestion. We can create a separate epic (In Jira tool) and user stories/tasks with different label and tag in summary to highlight these user story/tasks are not really related to product development and sprint goal. But we are doing along with product deliverables.

[3] We can also do these activities before we really start Sprint 1. Basically the ground work timeline. In this time frame we can work on the high level release plan, cross functional team formation, team trainings (related to development, processes, testing, BDD, automation testing, etc.), setup up the development environments, Product backlog grooming, Optimizing the Definition of Done (Take the organization level DoD and add more related to product).

[4] In SAFe that is the reason we have the "Innovation and Planning Iteration".

Innovation and Planning Iteration The Innovation and Planning (IP) Iteration occurs every Program Increment (PI) and serves multiple purposes. It acts as an estimating buffer for meeting PI Objectives and provides dedicated time for innovation, continuing education, PI Planning, and Inspect and Adapt (I&A) events.

https://www.scaledagileframework.com/innovation-and-planning-iteration/

Thanks.

Vijay KM

Thank you all for your insights – very, very helpful. I’ll try to address the main points, apologies for the long answer.

How does the self-managing team wish to handle this...and why are management deciding what work they ought to make visible on their board?

The team is fine with having these in Jira – some members wouldn’t even check the Excel, so it makes it more transparent for everyone. As for management, the argument was that the team should be aware of all the work that was being done. I agree with the argument but not so much with how it was handled.

It's totally OK to keep track of this information in the same Jira project using issues. In fact, it's what I'd recommend. However, I'd use either a specific non-developmental issue type or a label so that way the board/backlog view used by the Development Team wouldn't have these on them. A separate board/backlog can be used to give the right people visibility into either just these issues or the overall state of the effort.

That is more or less our approach now. When creating the issues, we used ‘Improvement’ (the other option was Bug) as it gives the issue a different icon on the Backlog and also labeled it with [BIZ Process]. Probably ‘BIZ’ is not the best as it implies that this is a Business task, when in fact the entire team should be responsible for it. We are keeping these on the top of the Product Backlog and the team is getting a periodic feedback on those (not every Daily, but at least once a week).

These issues are not estimated and are not being included on the Sprint. Our Agile Coach struggled a bit with this and asked if we could split it and include on the Sprint so it can also be considered part of the increment. The team said that it was not possible as this is more of an ongoing task and not really part of a Sprint (trainings, for instance, aren’t given at the end of each Sprint, but closer to the end of the project, and can be prepared along the way). Knowing the product, I would agree with the team and to be honest I also find it a bit hard to create Stories with goals such as ‘training is scheduled’. I would be inclined to agree with Simon’s suggestion of including this on DoD.

If the Scrum Team is responsible for the work and it is directly related to the Product, why wouldn't it be included in the Product Backlog?  If the Development Team is involved in those activities, it should also be included on Sprint Backlogs. And I would argue that without success of projects the product is not going to be successful either.  Implementing a new feature in the code base but not setting up the users for success in using it doesn't seem like a successful product strategy.

Completely agree with you, and in the end that is exactly what we are struggling now. How to include this on the PB if the team says that it doesn’t make sense to split in a way that it can be included on the Sprints.

The person that is responsible for these ‘Biz tasks’ is not doing any development work, so my first idea was to treat them as a 'Stakeholder' rather then being part of the Scrum Team. However, even though I would still receive periodic updates, the team might lose the transparency on what’s being done, so I quit this idea.

We can also do these activities before we really start Sprint 1. Basically the ground work timeline.

Usually before the start of Sprint 1 that is more or less already aligned, but more on a high level (eg. “deliver documentation until October”, “schedule training for November” and so on). The work that is done during the project is more of detailing this.

Thank you!

If the Development Team is doing the work, I'd suggest putting the items on the Sprint Backlog. Even if the work cannot be completed it one Sprint, it will require the team to devote some level of their overall capacity to it. By putting it on the Sprint Backlog, it would be more apparent to stakeholders outside the team that some level of effort is being taken up by the work. Seeing it on the Sprint Backlog may also help the team to organize around this work at the Daily Scrum. I'm seeing very few downsides to the increased visibility and transparency.

I do find it unlikely that there is no way to split the work up into units that can be delivered Sprint-by-Sprint. I'm not going to say that all work can be split - there may be some things that fall differently than a Sprint cadence or may be tracked and require intermittent involvement over several Sprints or any number of things. However, a lot of work can be split up.

The person that is responsible for these ‘Biz tasks’ is not doing any development work, so my first idea was to treat them as a 'Stakeholder' rather then being part of the Scrum Team. 

The approach that has been taken by many of my teams is to treat this individual as part of the Product Owner role. The Product Owner is responsible for deciding when and how to deliver the potentially releaseable increments to the stakeholders.  These "biz tasks" seem to be part of the delivery process so technically they could fall under the Product Owner's domain. I am going to venture a guess that the development team will provide input to these activities so having it as part of the Scrum Team's work makes much more sense. 

@Thomas, Two options 1. since you're using Jira, why not adding a kanban board to your scrum project? 2. Personally, I don't like creating a lots of filters. another option is to create a separate Jira project using kanban template. You can use "Linked issues" to maintain the references.

Why not the self-organizing team handles this, why management is involved into making a decision?