Changing priorities of items in the course of time
Hi
Our company has been following Scrum for some time now. Currently we have been having some complaints from within the dev team that projects taken up are not completed but pushed aside and new ones are being given more priority.
To describe a bit further, our dev team has 8 developers and so we have multiple projects running in parallel but all of them have the same Product log and is managed by the same Product owner. We start with a Prj 1 and Prj 2. We do some items in them for 2 sprints , finish the items defined , however there are some other parts of these that are planned to be done later in the coming sprints.
Then once the PO has the meeting with the stakeholders , then they bring in new projects and the priorities change.
So Prj3 and Prj4 are added to the backlog and the dev team is asked to work on them in the coming sprints.
We are able to complete the definition of Done on the items we take within the sprint and make a releasable product. But the complaint is that now Prj1 and Prj2 are out of the scene and no dev work is done on that.
Is this usually how it works when priorities from stakeholders change or is there something we can do to improve this situation.
We have a scrum master who is also a developer among us.
I'd be inclined to look on the bright side:
- you are delivering working product each Sprint, and
- you have a Definition of Done that is appropriate, and
- you have Product Owner who appears to be satisfied and who is able to prioritize the Product Backlog in terms of business stakeholder value.
Many would be glad of such things. I think that at least part of the team's problem is that work on the Product Backlog is being grouped in terms of "projects". The way the work is being actioned suggests that these groups are in fact epics or themes, or perhaps even an articulation of BAU work. In any of those cases it would be reasonable for a PO to focus on the priorities from each instead of trying to see any one grouping through to completion.
It sounds like the sprint is continuing working from an old backlog and being left to finish even though priorities have changed and the sprint backlog no longer reflects the product backlog priorities. Scrum should be adaptable and if the prioritise have changed so significantly that the sprint goal is no longer valid the sprint should be cancelled by the PO. If the changes are less significant items should be replanned during the sprint
I think talking about projects doesn't help.
To me it sounds like there is a breakdown in communication between the PO and the stakeholders or perhaps the PO is not really empowered properly to be the PO. Perhaps the PO and stakeholders should have more regular meetings and there should be more transparency so that everyone can see what is being worked on. Perhaps these meetings between the PO and stakeholders should be in front of the current sprint backlog so they can see what the hell you guys are working on.
Perhaps shorter sprints would help by finishing before prioritise change so significantly.
Hope that helps.
It isn't unusual for circumstances to change and therefore, priorities. If the changes mentioned were indeed driven by such a situation, there isn't any problem with the process or the organisation. In fact, Scrum seems ideally suited to the organisation, enabling it to respond effectively to change. In this situation the only problem is the team demotivation that can arise from seeing its work apparently getting junked all the time - but throwing good money after bad, whatever the process you follow, is also not going to have a positive effect in the long term
If, on the other hand, this seems to be happening because the Product Owner is picking the wrong product/project items to work on, it should be tackled by questioning these decisions in the Sprint Retrospective, at the very latest. Perhaps it's a matter of the PO not understanding his/her role correctly. Or it could be that the stakeholders are giving incorrect information to the PO or placing unreasonable demands and the PO is unable to resist their pressure. The Scrum Master should educate the PO/stakeholders as relevant and ensure action is taken to remedy the situation