What are the best ways to handle incomplete work at the end of a sprint?

Work happens. Whatever happens is complete in some sense. By definition, it seems to me that “incomplete” is about work that *doesn’t*, or *didn’t* happen. But when we think about it, over a given period of time, very little happens and a whole universe of things doesn’t happen. A more interesting question: what makes people believe that any particular desired thing will happen without interruptions, obstacles, surprises, distractions, or epiphanies? If we recognized the possibility of trouble, we’d have a different perspective on what we can hope to be “complete” in any given time.

Incomplete work at the end of a sprint can be a great way for a team to improve their definition of done. I like to look at the unfinished work for patterns then compare the patterns to the DoD at the retro. Having real (and recent) examples and scenarios can help teams have the retrospective conversations they need to have to improve their DoD.

At some point there will be unfinished work and sometimes at no fault of the team. Unforeseen challenges, changes in priorities, overcommitment or underestimation of task effort, scope creep, and intentional decisions by the team. The takeaway is finding out why and making a plan to mitigate the event in the future as much as possible.

The underlying framing of this question makes several potentially harmful assumptions. The biggest causes of incomplete work is the nature of the work itself. That begs the question of whether our approaches are fit for purpose. The majority of carryover happened because the team learned something they did not yet know when they sized the work. Perhaps this was a dependency not surfaced prior. Perhaps they ran into a severe impediment in exploring work they had not done in a particular environment. Scrum can be very opinionated about certain outputs like "velocity" when the more advantageous focus is on the cycle time and flow that signals true adaptability and responsiveness. This is more about perception at times, than reality.

Isn't the matter a case that expextations were not fulfilled? Not as a matter of lost momentum or enthusiasm (although it could be if remedial attention is not exercised) but the condition realities that presented themselves in the herexand now. There might even be the off chance that uncompleted work was the reality that what was plausible has now become less so from a value perspective. The upshot was whether we gained information that we can make future adjustment from, how we managed uncompleted work (if still relevant) and controlling all forms of fallout impact if there is any. As Michael Bolton pointed out that in the grand state of things a solution is really never 'done'.

The best way to prevent incomplete work is to complete it! The most important discussion (at a daily standup or more frequently) is: Given this piece of work and what we know now, how can the team complete it? Do we need help from another team? Do we need to stop doing something else? Do we need to rethink the approach? Do we need to work late? All the grooming, estimating, and planning has been done. But now that we've been working on it, we understand it better. What will it take to complete it?

Prioritize remaining work by business value, then transparently reassess and communicate sprint goals. Demo completed work, carry over unfinished tasks, and split large user stories for incremental progress. Address dependencies, allocate buffer time, and conduct retrospectives for continuous improvement. Foster transparent communication, refine estimation practices, and consider swarming on critical items to enhance overall sprint effectiveness.

How to prevent incomplete work: → Check for potential dependencies → Allocate more time for requirement analysis → Have more team members work on the same task → Have dedicated team members to address critical issues → Conduct regular feature demos internally and for the Product Owner → Establish efficient channels to speed up communication (Team - PO - Stakeholders)

Adjusting sprint duration just because there is incomplete work (as quoted in this section) is NOT recommended. In Agile/Scrum we fix the sprint duration and focus on finishing as much of the sprint goal as possible and the team helps each other out. Instead of focusing on changing the goal post (i.e., sprint end date), scrum team should focus on maximizing business value from the product and strategize how to handle the remaining work.

Handling incomplete work at the end of a sprint requires a balanced approach. Carrying over tasks to the next sprint can maintain continuity but risks accumulating backlog and may impact future sprint planning. Splitting tasks into smaller, manageable parts is effective for maintaining velocity and focus, though it requires careful reevaluation and additional overhead in planning and testing. Canceling or postponing tasks that are no longer relevant can streamline the workflow, but it's vital to ensure transparent communication with stakeholders to realign expectations and priorities. I

Carrying forward the incomplete work makes a lot of sense but before that decision is taken, the scrum team should have a transparent conversation with the product owner and let the PO shortlist the most valuable user stories for the next sprint. Worrying about velocity or splitting tasks into smaller chunks so you can calculate some partial credits for the sprint are all administrative activities which are outcomes of an organization that thinks low velocity = low productivity and the team is overcompensating.. Sometimes work remains incomplete and the team needs to collectively handle it with the product vision in mind and not short-term statistics.

Conducting a comprehensive retrospective at the end of each sprint is crucial for identifying the root causes and implementing adjustments to enhance future planning and execution. This aligns with the Agile principle of continuous improvement, emphasizing learning from experiences to enhance the efficiency of future sprints.

Simple continue those in the next sprint. Just see those as a guideline what you could complete in a sprint. There are always other unexpected interruptions (like bug fixes) or other challenges (helping colleagues, depending on other teams) which generate more value. As long as the team delivers what is promised for a certain date and that the average of burned story points is constant. Some stories are difficult to break in smaller spieces, although development and test. Btw we log a decision items, so it always can be traced back.

Learning from incomplete work in Agile involves reflective practices and continuous improvement. Use sprint retrospectives to analyze the root causes of unfinished tasks, focusing on process adjustments and team dynamics. Update estimation and prioritization techniques based on these insights to enhance accuracy in future sprints. Additionally, engaging with product owners, stakeholders, and customers can provide valuable external feedback, helping to align expectations and validate assumptions. This holistic approach not only addresses the immediate issue of incomplete work but also fosters a culture of learning and adaptation within the team.

Analyze where things got stuck. Was it a lack of resources, unclear requirements, or technical challenges? Addressing bottlenecks prevents future sprints from hitting the same wall. Capture lessons learned from the incompleteness. Document what went wrong, how you adapted, and what you'll do differently next time. Knowledge is power, especially in the sprint arena. Use the retrospective to dissect the incompleteness. Discuss openly, identify root causes, and brainstorm solutions to prevent similar situations in future sprints. Learn, adapt, conquer. Continuously improve your sprint process based on experience. Consider smaller sprints, different estimation techniques, or even alternative methodologies like Kanban if needed.

Incomplete work can come to a lot of different sizes. Can be left ove just 10 minutes to finish or a good size work that you may need multiple days to finish off. As general principal your work should be counted. So a good approach is to close the ticket so you can count the work for the sprint and to open a new one for the next sprint. Personally I would not do that if the left over work is less than 1hour. I would prefer to roll over the ticket to next sprint. Another consideration is whar type of incomplete work is. As an example a developer task to finish off a code ot may be mandatory to be completed. An infrastructure task that may is not absolutory necessary may cen be rescheduled and bundled with other infrastructure tasks.

Decide whether to carry over the incomplete work or re-estimate it. Carrying over allows for continuity, while re-estimating ensures accuracy based on updated understanding. Clearly document the status of incomplete work, including remaining tasks, estimated effort, & dependencies. Communicate this information transparently to all stakeholders. Delegate incomplete tasks to team members with appropriate skills & capacity. Encourage collaboration & knowledge sharing to ensure efficient completion of remaining work. Prioritize finishing features that contribute to the Minimum Viable Product (MVP), ensuring core functionalities are delivered within the sprint timeframe.