Stories in test at end of sprint

Question

We are a small team (3 devs and 2 testers) and we have successfully used Scrum for 6 months, despite being a really small team for this methodology. I am a rookie as a Scrum Master.

Now, we have started to experience problems with Sprints ending with tickets that are finished by devs -in theory - but tester has not had enough time to test them.

How should we handle this? Extending the Sprint is not allowed, so moving the tickets to the next Sprint seems to be ok, but how we could estimate them? Since testers could find big problems that could drive new fixes.

Edit: More information: we had 7 tickets... this main ticket was took first, and it tooks from start to end of sprint, so we have just ONE finished ticket. It is the weirdest sprint that we had. Of course: the worst estimation ever, but our retrospective will look so strange with just one finished ticket, and the other with development finished but nothing of test... Administratively what should I do? back to backlog and starting again? estimating the original story point - dev time (that is already "finished")?

Answer 1

TL;DR

You need to inspect-and-adapt your entire estimation and goal-setting process. However, in the short term, incomplete work should be placed back on the Product Backlog, re-prioritized, and re-estimated.

Analysis

Administratively what should I do? back to backlog and starting again? estimating the original story point - dev time (that is already "finished")?

You should have a Sprint Goal. The goal of a Sprint is to achieve the Sprint Goal, not to do lots of tickets. Without a Sprint Goal, you're not really following the Scrum framework, and you won't really be able to properly evaluate the success of the Sprint.

Regardless, your specific question is about what to do with work that isn't really done. If your Definition of Done includes completion of QA, then the Product Backlog Item is simply incomplete. It isn't partly done, it isn't sorta-kinda done, it's just not done.

When Product Backlog Items aren't complete at the end of a Sprint, they go back onto the Product Backlog to be re-prioritized by the Product Owner. The item may or may not remain relevant, and only the Product Owner can determine if there is still value in allocating resources for it in a future Sprint.

If and when the work comes back into scope for Backlog Refinement or Sprint Planning, the work needs to be re-estimated. The Scrum Guide says:

All incomplete Product Backlog Items are re-estimated and put back on the Product Backlog. The work done on them depreciates quickly and must be frequently re-estimated.

How much work was done on the item previously is irrelevant. The work must be re-estimated to determine how much effort remains (given knowledge about present team capacity and cumulative lessons learned, among other things) to implement the feature within a new Sprint. Historical estimates and expended effort should be discarded as data points, because time boxes are ephemeral; what matters is effort remaining.

Answer 2

Discuss in the Retrospective.

There's a limit to how much advice can be obtained from strangers on the internet. Your Team is presumably aware of the problem, and Scrum prescribes a self-organizing Team. So discuss the issue and brainstorm/evaluate possible solutions during the Retrospective.

That being said...

Have QA be involved during the Planning Meeting.

Specifically, during estimation. Estimates should be for the effort needed to get the story Done℠, not just development-done. That being said...

Focus on the Sprint Goal.

So you're not completing all stories, okay, no big deal. Are you completing your Sprint Goal? That's what you should be focusing your efforts on. If you have your Sprint Goal entirely in dev-done but QA is behind, maybe it'd be best for developers to ignore the 'stretch' stories and help QA instead? Just a suggestion - again, consult the Team.

If you don't have a Sprint Goal, then you have bigger problems than incomplete stories.

Answer 3

Now, we have started to experience problems with Sprints ending with tickets that are finished by devs -in theory - but QA has not had enough time to test them

estimating the original story point - dev time (that is already "finished")

Try not to think of testing as a QA activity. It is a team activity.

QA's may run tests, but they also need to speak to the Product Owner / Developers about issues and bug fixes will usually involve the developers. Also, consider activities like root-cause analysis, test automation, code quality metrics, etc.

If testing is not completed successfully the ticket is simply not done. Return it to the backlog and if it is again prioritised you will need to re-estimate it.

we had 7 tickets... this main ticket was took first, and it tooks from start to end of sprint, so we have just ONE finished ticket

This is an excellent learning opportunity. As a team, think about why this happened. What can be done to prevent it happening again in the future?

but how we could estimate them? Since QA could find big problems that could drive new fixes.

This is why a lot of Scrum teams adopt approaches like test driven development and behaviour driven development. Bugs are notoriously difficult to estimate so it makes sense to spend time preventing them occurring rather than fixing them.