We've implemented classic Sprints for our team, but as a consulting agency (CRO agency), we directly engage with clients, collaborating on their development, design, copywriting, and more. Despite having a meticulous sprint plan with risks accounted for, once in a while we encounter urgent external tasks from clients.
Example.
Sprint Plan:
- Product manager plans to develop 1 hypothesis, estimated at 8 story points.
However, midweek, we receive the following external requests:
- Review and address comments in the design (1 story point) - Perform pricing calculations for the new products (5 story points)
Problem:
Both external requests are important for the business, and the client insists on completing them within the week. Consequently, the product manager's initially planned 8 story points escalate to 14.
Goal: I aim to document protocols for handling such cases during running sprints, outlining responsibilities, step-by-step procedures, approval processes, and communication channels (standard practices, nothing extraordinary).
Question:
I intend to incorporate a priority 'calculator' into the instructions so that other project managers can assess whether an external request warrants immediate attention or could be deferred to the next sprint. While numerous prioritization methodologies exist, most are geared towards standalone projects or feature development, but somewhat less applicable for different business-wide requests. Much appreciate any ideas, insights, thoughts and opinions on which prioritization methodology would you choose for managing external business requests of such nature.
PS: apologies for the huge spaces in formatting, tried to remove them, but it keeps the spaces.
I would question whether a sprint-based approach is suitable when there are likely to be ongoing reprioritizations of new and existing work items on an ongoing basis.
Have you looked at a continuous flow approach without using sprints where as team or individual capacity frees up, the next highest priority work item is pulled and worked through to completion?
Kiron, thank you very much for your attention to this matter.
Indeed, we have previously explored the continuous flow approach. We are now experimenting with sprints in an attempt to stabilize the workload for certain teams. This is aimed at mitigating the fluctuating workloads, where some weeks are relatively manageable while others become exceptionally challenging due to simultaneous occurrences across multiple projects - and sprints are pretty nice in terms of the fixed scope of story points planned. But such cases as I've described do occur, and I need to figure out how to assess them, at least for the sprints test-drive period.
In that case, I'd suggest the team being conservative about the amount of their capacity they will forecast for planned work - whereas normally, a team would forecast up to 90% (allowing 10% for unplanned surprises, underestimated work items and so on), they may need to drop that ceiling based on the volume of unplanned work.
Kiron
...
1 reply by Donna Harvin-Graham
Mar 07, 2024 10:34 AM
Donna Harvin-Graham
...
I completely agree with this perspective. I also wonder for the tickets that are being created, do you have one for misc. items that can be pointed high enough to deal with the business requests. As an example, my (agile) team deals with projects and O&M. Because of this, the developers need tickets to deal with the ad-hoc O&M requests - in addition to providing support to various projects. I find it is a balance for a shared services team and it seems to work well for us.
Senior Projects Manager | Field & Marten AssociatesNew Westminster, British Columbia, Canada
Mikhail, in principle, I do agree with Kiron. I believe utilizing Kanban will help with your issue. That said, if you accept urgent tasks that were not originally planned within the sprint then this might compromise your sprint goal so I don’t think this is a good practice even if the team becomes more conservative in their estimates because this is a short term solution. You should look at a long term one. Saving Changes...
Thank you, I do agree with everything you've mentioned. We're just giving a test drive to sprints and still need to adjust a lot of things based on the practical experience of this approach. We even haven't faced such external requests yet, but I foresee such cases and have to get the team prepared. So I just wonder if there is some estimation/assessment methodology that would be applicable for the unplanned business requests.
We still can always rely on the personal experience of each project manager in external tasks assessment, however I just don't want to keep the instruction documentation unspecified (just classics of documentation, when enforcing a rule, provide a means to comply)
Thank you!
...
1 reply by Rami Kaibni
Mar 07, 2024 12:48 PM
Rami Kaibni
...
Mikhail, normally when you pull backlog items and plan a sprint based and then set a sprint goal, you should ensure that the sprint goal is not compromised. If there are additional tasks requested during the sprint by the client, then I recommend you add them into the backlog, prioritize them, and taken them on within the following sprints depending on their priorities. In very rare cases, if the tasks are minimal, and complement the sprint goal, you can take them on within the ongoing sprint but you should ensure that while change is welcome, your stakeholders do understand the ramifications of adding extra tasks to an ongoing sprint and that it might not be entertained immediately.
Saving Changes...
Donna Harvin-GrahamDirector, Financial Processes & Systems| American Psychological AssociationWashington, DC, United States
Mar 06, 2024 9:54 AM
Replying to Kiron Bondale
...
Mikhail -
In that case, I'd suggest the team being conservative about the amount of their capacity they will forecast for planned work - whereas normally, a team would forecast up to 90% (allowing 10% for unplanned surprises, underestimated work items and so on), they may need to drop that ceiling based on the volume of unplanned work.
Kiron
I completely agree with this perspective. I also wonder for the tickets that are being created, do you have one for misc. items that can be pointed high enough to deal with the business requests. As an example, my (agile) team deals with projects and O&M. Because of this, the developers need tickets to deal with the ad-hoc O&M requests - in addition to providing support to various projects. I find it is a balance for a shared services team and it seems to work well for us. Saving Changes...
Senior Projects Manager | Field & Marten AssociatesNew Westminster, British Columbia, Canada
Mar 07, 2024 3:47 AM
Replying to Mikhail Klimenko
...
Kiron, Rami,
Thank you, I do agree with everything you've mentioned. We're just giving a test drive to sprints and still need to adjust a lot of things based on the practical experience of this approach. We even haven't faced such external requests yet, but I foresee such cases and have to get the team prepared. So I just wonder if there is some estimation/assessment methodology that would be applicable for the unplanned business requests.
We still can always rely on the personal experience of each project manager in external tasks assessment, however I just don't want to keep the instruction documentation unspecified (just classics of documentation, when enforcing a rule, provide a means to comply)
Thank you!
Mikhail, normally when you pull backlog items and plan a sprint based and then set a sprint goal, you should ensure that the sprint goal is not compromised. If there are additional tasks requested during the sprint by the client, then I recommend you add them into the backlog, prioritize them, and taken them on within the following sprints depending on their priorities. In very rare cases, if the tasks are minimal, and complement the sprint goal, you can take them on within the ongoing sprint but you should ensure that while change is welcome, your stakeholders do understand the ramifications of adding extra tasks to an ongoing sprint and that it might not be entertained immediately. Saving Changes...
Hi Mikhail, only seeing this now. Maybe some client contacts can be convinced to occasionally attend a backlog planning meeting, possibly remotely. That would also be an opportunity to define tests/acceptance criteria. As others have stated, it is okay to assume that only say 80 or 90% of the work is defined a priori. The examples you give do not look like particularly unreasonable requests. So, another potential solution is to give time critical feedback quickly and to split out further work to a later sprint. Saving Changes...
"I do not know anyone who has got to the top without hard work. That is the recipe. It will not always get you to the top, but should get you pretty near."
Community Champion
