Items not finished - motivation needed?
Hi,
one of my teams struggles with unfinished stories during last 3 sprints. Most probably this is lack of cooperation issue because often they take on new items when all the other tasks are done or taken by others. They claim that it's impossible to split the work into smaller tasks that could be done by more people in parallel.
On the other hand, they talk quite a lot when they face technical problems, maybe not pair programming, but surely "pair analyzing". And there were successful sprints when almost 100% of the items were done (we don't have sprint goal).
For sure, this needs to be analyzed further on a retrospective but I also have an idea/question. The product they work on has no deadline and is to be used by an internal customer. All of this results in the lack of the external motivator and so there's no actual need in finishing items in the given sprint.
I think of visualizing the estimates and how they impact some important events' dates (e. g. product demo; still, nothing bad happens when the date changes). But I'd like to give some additional motivator for finishing items in a Sprint and reaching stable velocity. Do you have any ideas what this could be? Do you have any experience with such projects?
Feel free to challenge my reasoning.
Regards,
Artur
Don't you think this shows how important it is to have a Sprint Goal?
There's no point in sprinting without a goal to aim for. Hence a Sprint Goal is not an optional part of Scrum, but is essential to the implementation of the framework.
The product they work on has no deadline and is to be used by an internal customer.
Actually, the timebox (deadline) for getting work done is the actual sprint. Why doesn't the internal customer hold the team accountable for the work that they forecast each sprint? Why doesn't the team hold itself accountable for this?
Why is the team working on items that apparently do not have a high priority with the company? Does this smell like Scrum to you?
What degree of training/experience do your development team members have with Scrum?
Please be careful in showing the team the potential consequences of their performance (missed dates, etc). While this is valuable to make transparent to both the team and the organization, it is a tricky approach, especially if they are not mature enough to understand the benefit of failure in an empirical environment (transparency, inspection, adaptation).
How’s the review sessions going on with the team? In my experience, I have seen teams missing to understand the purpose of this review ceremony. It is not only important to make sure that the DOD is met before a PBI can be marked done or not, it’s also key to present the increment to stakeholders and elicit feedback.
I experience an increased motivation and accountability by the teams that receive constructive feedback, directly from the stakeholders on how the value can be enhanced further with subsequent increments. It also is a forum where stakeholders have a dialogue and speak of their key KPI’s and how the developed increment by the team, may or may not help with their targets/goals.
Don’t you think the team will feel more accountable and motivated if you as a Scrum Master, ensure that the review ceremony is conducted consistently after every sprint, with the stakeholders and not just the PO?
Hi Artur , you have mentioned many issues here , I could suggest few things based on information you have provided
- When you say work cannot be split small enough : I would say work with your product owner/Business analyst to refine the stories . This is something you need to coach/ work along with your PO to bake proper stories for the team. Keep more refinement sessions, target for logical split of the stories . Not sure if you are already doing but 3-amigoes sessions can help here. Take your PO , Developer and tester to prepare the stories before sprint planning . Do the T-shirt sizing, if they cannot size it in the 3-amigoe then sprint planning would even more difficult.
- Sprint Goal, as rightly suggested by Ian is another thing which can help here .
- You have mentioned that team doesn’t do pair programming but they do the pair analysing, why don’t you ask them to do the actual pair programming . It should help. In fact, if you think they still can’t break the stories further then suggest them to do the Mob programming .
- Another thing about internal project and delivery dates missing, why don’t you set up internal release dates, put it on JIRA/RALLY or whatever tool you use . Showcase the release burnup somewhere in the team area .
- Set up the work in progress limit if you observe they are picking up new tasks before finishing the previous one .
- One more thing you can try is take a big dip on velocity once , ask the team whatever they can deliver in the sprint . Take their words and don’t take more work in the sprint . If team can complete the sprint successfully then it would increase the confidence in them and you may increase the velocity slowly. Make team OWN it .