Operational Work in a Sprint?
So I have three hybrid teams. All teams have both project work and operational work. The project work fits well with in the scrum process. As for the operational work we use the Kanban board feature in Jira to limit the WIP. Up until a few weeks ago the Kanban board was enough and just existed. However, the team wanted the information in the Kanban board to be captured in the sprint so we can generate the same kind of reports that we do for the planned/project worked so we can put these reports side by side and see where we can do process improvements or tweak capacity as well as show management our pain points in terms of getting additional resources. I went ahead and created a new scrum board that would capture the Kanban board in a sprint. So each team will have three boards, the Scrum board with the project work, the Kanban Board and the Scrum Board with the operational work from the Kanban board as it is being worked on within the sprint. Please note my teams have to balance project work and operational work as mentioned before. 40 percent of the teams overall capacity is dedicated to project work and 60 percent to operational work. The issue that we are facing is all the work that is not captured between the time of closing the sprint at 9:15 AM and starting a new sprint at around 1:30PM. There is about a 2-3+ hour chunk of operational work that is not captured. Granted the team is participating in Sprint Review, Sprint Retro and Sprint Planning for most of the day when that happens, there is still the fact that the incoming operational work is not being captured in the sprint but outside of it. I was wondering if anyone had any ideas. The teams are a bit stuck when we attempted to talk through a solution however everyone is at a stalemate. I was thinking of running a few sprints and then finding out the velocity of operational work that exists outside the sprint over time and adding a buffer based on that velocity of operational work that is not captured. We can then over time add the velocity to the operational work that is captured in the sprint.
I don't understand why you would have two separate boards for the team. Splitting up the work onto multiple boards doesn't promote visibility and transparency into what the team is doing. Mechanically, in Jira, you can set WIP limits on Scrum boards while getting a single point to see what work is before the team. This configuration of the tool seems to be a lot more troublesome than it's worth to maintain and keep track of, even if it's mentally understanding where things are. Adding the third board just adds to the complexity.
I also don't understand how the team is doing work between 9:15am and 1:30pm if they are in Sprint Review, Sprint Retrospective, and Sprint Planning. It seems like if the team is actively participating, they would be unable to do any kind of work, operational or project.
As far as planning goes, I think it's much more straightforward. Let's assume that you have a team of 5 people each working a 40 hour week. That means that there are 200 hours per week. If 40% of the time is project work and 60% is operational work, that means that 80 hours are project work and 120 hours are operational work each week. However, we know that people are not able to work at full capacity - things like overhead work, unplanned stuff, and context switching. Different people use different numbers - Capers Jones uses something around 85%, I like to use 70-75%. I'd say that you have between 56-60 hours of project work and 84-90 hours of operational work. You can use these to check your Sprint plan and check with the team that the Sprint Goal can be achieved within about 56-60 hours and that the operational work takes up about 84-90 hours.
Thomas thank you for your input, I just want to clarify a few things. The Kanban Board that we have was created by default when our scrum board was created. It was not something that the team had a choice in. All of our scrum teams have a Kanban board if they are hybrid and have operational work. The problem with the Kanban Board alone is that we could not track the operational work that was done within the sprint efficiently. This became a manual process and it was tedious to identify that work. Since we are a hybrid team our operational work is included in our sprint review. Our leadership wants to know what kind of operational request come in during the sprint to understand where resources are needed and to better explain why some work gets pushed by operational work. Of course the team has their velocity and capacity however if operational request comes in at high volume or something breaks then the planned project work will have to suffer. Those break fix items live in the Kanban board also occasionally we have operational work that take effort but they cannot be counted as project work based on the nature of the work being performed. At first we wanted to just add a filter to the Kanban Board that we already have to include an option to only look at operational work in a current sprint however we got push back since in my org the Kanban Boards are to be left as such that we are not allowed to directly manipulate the configurations of the board. Thus the reason of creating the third board. Also to note when we do our planning we use a focus factor 40% for project work and 60% for operational work. From that we subtract the ceremony times and any group meeting that the entire team my have to attend that does not result in work. Then we account for holidays and planned time off.
The issue that we are facing is all the work that is not captured between the time of closing the sprint at 9:15 AM and starting a new sprint at around 1:30PM
Sprint retrospective concludes the sprint !. A new sprint starts immediately after the conclusion of previous sprint. Sprint planning initiates the sprint. Try to not leave time between the 2 sprints.
If you follow Kanban workflow for operation works, Then you may try to measure 'Cycle time' and 'Throughput' instead of Velocity.
In Scrum, when one Sprint ends less than one microsecond later the next Sprint begins. This is for the purposes of transparency. The Sprint boundary is very crisp, and it provides a sublime moment of transparency over the work that has been Done and remains to be Done for a product.
Is the operational work you describe even on the Product Backlog? If not, the enforced "hybrid" and disempowered nature of your team ought to be exposed as an impediment to product delivery. On a positive note it seems the boards you do have are already reflecting that truth.
"In Scrum, when one Sprint ends less than one microsecond later the next Sprint begins."
Should not the Sprint Review, Sprint Retrospective and Sprint Planning before the next sprint starts?
During those three ceremonies the team is in attendance, so the team is not working on anything related to a sprint but participating in those meetings.