What to do with Stories still in progress at the end of a sprint

[Thandi Velaphi]

Good day team, I feel like i'm failing my team and really need guidance on this one please. Perhaps i'm not coaching them correctly. When the team reaches the end of the sprint, I notice alot of stories are still sitting in the 'To-Do' and 'In Progress' state. This obviously goes hand in hand with planning for the sprint and not taking on more than they can chew so to speak which i've reiterated many times to the team. What is the rule of thumb for the end of the sprint regarding unfinished work. Should the stories be moved into the next sprint or backlogged then discussed at sprint planning based on the teams velocity? I hope my question is clear?

Thanks

Thandi

[Karim ABO HASHISH · Accepted solution]

Hello Thandi,

It's ok , with some patience and few simple techniques it could easily get better.

Let me share with you some practices that could help. Feel free to try when applicable.

1. During the sprint planning try to engage the team members instead of assigning tasks, ask them about their opinion and who would like to work on different stories, thus they will willingly acquire the ownership.
   
   
2. During the sprint planning try to be very clear about the sprint goal and its business significance.
3.  People love stories. If possible, tell them the story about specific requirement and explain the stakeholders pain or problem, this will emotionally motivate them to take the initiative and come up with a solution.
   
   
4. Think about the "limit work in progress" (WIP) technique. check this article. feel free to search for others.
5. Try to engage more than one team member on a single user story, this will increase productivity and boost team work.
   
   
6. If the sprint planning and sprint review occur at different slots, move the in-completed stories to the backlog and wait for the next sprint planning to engage and probe them for taking the ownership. Give them the choice to decide the amount of work, i know it's not always easy to give people the full control but it's a learning process, we all learn and develop.
7. Try to invite them when possible to stakeholders discussions so they get better sense of the business value they are bringing in. This will also demonstrate transparency and enhance the trust relationship, One Team approach and support level.
8. Conduct SCRUM meetings. Ideally it shouldn't exceed 15 minutes, for me i do 30 minutes daily scrum meeting. Feel free to make it daily or several times per week, you know better. During this meeting you can make quick follow-ups and offer support if needed whether from your side or from within the team, it will improve the team chemistry and limit silos.
9. Develop sprint dashboard that shows the sprint health, and some team statistics. Share it during the SCRUM meetings. it will motivate the team to stay on track and minimize the carry over at the end of the sprint.
10. After one or two sprints conduct a retrospective. it is a team collaborative exercise to exchange about the team working practices (not the features we deliver) and usually it's about what we did well, what we could do better, ..etc. Try to tune your model according to their feedback.
11. Try to make some team building events from time to time in order to maintain the team spirit and improve team work.

Agility is a learning culture. we always inspect, seek feedback, learn and adapt

Feel free to try one or two techniques at a time. introducing small changes is always easier to apply.

Finally inspect and repeat the learning cycle with adding or removing extra little changes.

Good Luck Thandi and wish you an enjoyable learning journey.

[Thandi Velaphi]

Thank you so much Karim. Ill definitely try some, if not all of these suggestions. Appreciate your response.

Kind regards

Thandi

[Renzo Arriagada · Accepted solution]

Hi @Thandi Velaphi !

There is really no "true" or "unique" way of working with issues that weren't completed by the end of the Sprint, but here's what I'd recommend:

• You should take the issues to the Retrospective and talk collectivelly with the team on what happened to those issues and try to find the root cause of why those issues weren't worked on. It's important to remember that you are not finger pointing people, you just want to get the team involved on working through the problems you are facing sprint to sprint.
• As for Jira, I recommend to send the issues to the Backlog in order to have time to plan accordingly at the begining of the next sprint, without rushing work just for the sake of getting those issues done.

Once again, these are all recomendations and I'm sure you'll come up with something that fits the work pace of your team.

I hope that was helpful for you.

Kind regards,

Renzo from Servicerocket.

[Thandi Velaphi]

---

Thank you Renzo for your answer aswell. I now have a few great suggestions that I can take back to my team..

Kind regards

Thandi