Scrum in crossfunctional teams of technical and non-technical members

Usually the larger and more unique a challenge, the harder it is to grasp. Can you clarify why -- in your situation -- it is the small and repeatable tasks that are proving most difficult to represent?

From your post, it seems that you have a Development Team composed of two silos: one that supports feature work, and one that provides run-time support.   This is not a Development Team by Scrum standards; instead, it is just a working group that is loosely connected (i.e. - having a single SM).

My initial thought is that these two groups should be separated into two different teams - one working in Scrum (feature work), and the other perhaps working in a Kanban fashion providing support to customers.   That way, the work by both teams is still made transparent, but the run-time support team doesn't have to try and adhere to a Scrum framework that may be difficult for them.

I'd agree with @Timothy that these are two teams.

If that non-technical work is needed for the technical work, you might want to look and see if that work could be done before or after the technical work is done.  If so, you may be able to get the non-technical part done ahead of time as part of refinement of the stories and set the behavior that the items are not ready to be pulled into the sprint until that work is done (i.e. the item is not "Ready").  

If the non-technical work is necessary and has to be done in conjunction with the technical work, then they should fall under the umbrella of the Development Team's Sprint. But do they have to be represented as stories? Couldn't they just be considered a task that has to be done in association to a story, especially given your explanation of repetitive and short in duration?  In that case, they don't necessarily have to be represented in the Product Backlog as a story.

Thank you for your insightful and quick responses. 

@ianmitchell & @daniel, i dont want to separate them into two different teams because they all work as part of a product team, and we are trying to build a product oriented organization, in which the team is present in the value stream from start to end. But i will consider that option if we fail to find a solution, or maybe something in between.

@timothy, i think that a potential possible solution could be differentiating all this non-technical tasks from the user stories, because they need to be done in conjunction with the dev tasks normally (although there is a big amount that will fall into backlog refinement tasks). But, my main concern is that reflecting all these tasks on the sprint backlog ends up being more tedious and time consuming than the value obtained from representing them. 

By the way, we already use kanban to represent the sprint work :D.

Thank you anyway, i will keep trying to find a suitable solution for my team with both your inputs.

Regards

my main concern is that reflecting all these tasks on the sprint backlog ends up being more tedious and time consuming than the value obtained from representing them. 

This statement jumped out at me for two reasons:

1. What are you using to measure the value of transparency versus non-transparency (reflecting work in the sprint backlog)?
2. Who specifically is taking on the responsibility of entering and reflecting work items in the Sprint Backlog?   If it currently happens to be you, I would advise trying to move away from that responsibility and establishing it within the Development Team
   
   
   
   The "Scribe" is a identified anti-pattern with Scrum Masters that you should try to avoid.
   
   
   
   https://www.barryovereem.com/scrum-master-misunderstandings/

Having worked in a non-technical team in two different companies some years ago we never were included in the sprints and it made perfect sense. Our tasks were pretty much always dependent on the technical team's performance and were seen more as a result of the technical team's work. Technical task done > allowing the non-technical team to do their jobs.

@timothy No no, i didn´t fall into that misunderstanding. It is the dev team + the product owner who manages the sprint backlog and the product backlog, and they are the only ones responsible for both artifacts, i just try to mentor them in doing so and i keep track of the correlation between what they are working on and what its reflected on our sprint board, trying to coach them in aligning both as much as possible in order to maximize transparency. 

The article you shared was really interesting in any case, thank you!

About the measuring transparency I don´t have any metric right now, although I could estimate it. I will look for a transparency metric, It is a pretty good idea, thanks! (If you happen to have any tip about this issue, let me know)

Are the technical and non-technical guys working in pairs, for instance, on the different items until they are "Done"? This would generate a common understandig and more developed team (towards the T-shaped people). If your goal, or the organizations goal, is to work on product development focus, this would be a good start.

i dont want to separate them into two different teams because they all work as part of a product team, and we are trying to build a product oriented organization, 

It is quite possible and common to have more than 1 team work out of a single Product Backlog. In that case you are a product oriented organization and able to coordinate work across both teams for a common purpose. 

I think everyone has given you a lot of perspective.  Hope it helps.  And come back to share more of this situation. It can help others, like me, expand our skills.