Best Practices for including bug-fixes and user-requests
I am looking for Agile standards or best practices, when it comes to including points for bug-fixes and user-requested changes in sprints. I understand that the beauty in Agile is that there is no "right way" to do things, but we are looking for some precedence/documentation of the best way to handle this. For context, here's the situation:
We've got three groups of people: Group A is the PMO, who manages the system, as well as the contract for development I guess we could say they are the voice of the development team. Group be are contractors, and they are the development team. Group C is the program side, they speak for the stakeholders/users, and they have to make the Division Director happy - they are led by the Product Owner.
The system already exists, but the Agile project is to enhance and add capabilities, as well as making sure that any new LRP (laws, regulations, policy) are covered. The system has a mechanism for users to submit change requests, if there's something not acting as it should, or if they have an idea on how to make it work better for them. Group A and B want to set aside a certain number of story points, per sprint, to be able to include any hot fixes, regulation changes, user changes, rather than just adding them to the backlog for them to be added to a sprint, when there's no bigger priority (there's ALWAYS a bigger priority). Part of the problem is that if user feel that they are not being heard, we will lose their buy-in on the system. Group C, the PO, doesn't want to set aside Story Points, because he feels that his management will feel that it is taking away from the high-priority items.
Is there a standard/best practice on how to calculate story points for this type of thing? Or is it strictly up to the Scrum Team?
Mara Hansen, What you have here requires more continuous planning that every Sprint planning. The scope is changing everyday because you are basically a team supporting a product that is already live mostly dealing with PRODUCTION Defects (Note: Bugs are basically incomplete work which needs to be part of the PBI that needs to be RELEASABLE and therefore bug free) and/or enhancements.
There are two suggestion I can make, both of which worked for me. You need to have a DevOps support team that is primarily focussed on making sure the application is running with agreed SLA downtime etc and fix any production defects that's bleeding money to the client (like a bug that is costing the client 9k per month due to not satisfying auditory or government regulation etc, real example !)
Another team completely focused on the actual product. Both teams need to meet (Scrum or Scrums or NEXUS can be used if you have more than two teams all together) to discuss the work that requires mutual attention. Like a feature from the backlog that gains priority as a result of several production defects or operation problems that it could solve (automating, clearing space automatically, automatically timing out a user's session to comply with the new security guidelines, automatic password reset to avoid redundant calls for a simple password reset to the support/operations team, kind of functionality, etc) Together these teams needs to focus on organizing their boards accordingly.
Option 2 is (especially if the total team is less than 9 still) treat the entire team as one but follow Scrum with Kanban
Either ways, you need to include kanban for the regular inflow of work (production defects and operational issues). Enhancements needs to be prioritized in refinement (team internal) and roadmap (product owner and his stakeholder) meetings. As usual a high priority enhancement can be added to the kanban and/or scrum (based on whether you one or two teams) board and scope renegotiated as long as the board is owned by the development team and not the PO or SM or any other stakeholder.
If a Development Team is uncomfortable with the level of technical debt being incurred, and wishes to repay it, there’s nothing to stop them from reserving capacity to do so each Sprint. No-one can oblige the team to undertake other work instead.
Is there a standard/best practice on how to calculate story points for this type of thing?
Standard? No standards in Agile or Scrum. Best practices? Everyone has their own best practices and they are usually determined after much trial and error.
Group A is the PMO, who manages the system, as well as the contract for development I guess we could say they are the voice of the development team.
The Development Team is their own voice.
You say that Group A and B want to do one thing but the PO(Group C) is against the idea. Why not suggest to everyone that it be given a try for 1 or 2 Sprints? Inspect and adapt as necessary to find a solution that works. Remind them that agile is about iterating on an idea until a good solution is found. That is how most people arrive at their "best practices".
Given that I'll give you a summary of how my teams have handled similar situations.
A Sprint Backlog is a forecast of what the team feels they can accomplish in order to deliver a "Done" increment of value. The Sprint Goal provides guidance to the Development Team on why it is building the Increment. My teams have historically built a forecast that allowed time for discovery of new information and adapting instead of setting themselves up to fail if they discover complexities. They frequently pull in new items from the Product Backlog (bugs, high priority requests, production outages) as the items are identified. The decision to pull the items in are made by the Development Team. If they feel that the introduction of a new item is going to endanger their ability to satisfy the Sprint Goal or deliver a "Done" increment, then the PO is brought in to help decide how to proceed. It is not unusual for them to negotiate pulling 1 or more stories out of the sprint in order to accommodate the "higher" priority items.
Notice that I said the Development Team will pull items from the Product Backlog. That implies that everything goes through the Product Owner or the Product Owner is aware of the item being added because the PO is ultimately responsible for contents of the Product Backlog. That allows the PO to maximize value being delivered from the work done by the Development Team.
Group A and B want to set aside a certain number of story points, per sprint, to be able to include any hot fixes, regulation changes, user changes, rather than just adding them to the backlog for them to be added to a sprint, when there's no bigger priority
Just to confirm, do groups A and B want to be able to add items into the Sprint Backlog mid-sprint for the team to work on, rather than waiting until the next sprint?
If so, I would recommend avoiding this. Once the items in the Sprint are specified during Sprint Planning, no new items should be added (unless the Development Team agrees). Any new work that is thought of during a Sprint that is not in the sprint should be added to the Product Backlog (and not into the current sprint). It's then up to the Product Owner to determine the priority, and if it's the next most important thing to work on, then it can be worked on in the next sprint.
Just to confirm, do groups A and B want to be able to add items into the Sprint Backlog mid-sprint for the team to work on, rather than waiting until the next sprint?
No, A and B want 10 points allotted, per sprint, to be used for any "quick fixes" or "User-changes" that are on the Product Backlot. They want to be able to include them in the sprint, during planning. But the Product Owner stops them and says, "X is more time sensitive, that needs to be done first."
Given the your last statement @Mara, I would say that sounds like it should be with exception that this statement from the Scrum Guide is not being honored.
For the Product Owner to succeed, the entire organization must respect his or her decisions.
However, as a Scrum Master I would bring the parties together to discuss this a bit more. It could be that the PO does not fully understand the importance of the issues and there could be an opportunity to improve the communication. Or it could be the reverse where the PO is privy to some information that the others aren't.
The other thing you can do is try to identify the value of the user requests up front. Ask them the following questions:
What is the problem you are trying to solve?
Is there a workaround for this?
How many minutes/hours/days does this issue take to resolve using the workaround?
What happens if we implement or fix this?
What happens if we don't?
I don't have a good way to ask this, but is the fix to solve an actual business problem or to remove tedium?