We are a small startup company with 2-3 project running simultaneously by 3 developers and 1 QA guy. We use Scrum and we encountered difficulties while we had a sprint with a user story, as small as we could shrink it, with more points than the sprint could hold.

We didn't want to estimate the tasks because we believe a user story is the smallest resolution we should price. Another example situation would involve a smaller volume user story that we didn't finish at the end of the sprint (1 Point = 1 Day).

What is best way to handle these cases in aspects of:

  1. Counting points for planning and execution of current and next sprint.
  2. Monitoring progress during and over sprints.

If you are a startup, you are starting to know how many points the team can manage in a Sprint.

Also, it is good if you focus on whats missing so you can finish you stories and your current sprint: An action plan.

With all these data you will be able to know how much work your team can do in the next sprint and have a better plan, and maybe you could change your measuments (ex. 1 day = 3 points)

If it is difficult for you to split the stories by functionalities, try to split them by technologies, users, or something different. That will help you to do tasks that can be finnished in less than a day. The developers should identify if there could be smallest parts of the history.

  • The team has been working together for a time and they know how to estimate their pointing, so on that side I know they are pretty close to reality. Is it common to split user stories? As far as I could dig the online world I understand that US are not supposed to be broken down to tasks for delivery in a sprint , even if there are several development sectors\specialties.
    – Omri
    Aug 2 '17 at 5:59

It's important to know why the story couldn't be broken down to be small enough. I suspect there could still be a creative way to deliver at least some of what's wanted, but it's hard to be sure without an example.

In answer to your questions

1 Story points are a useful way to help the Development Team to provide a forecast during the Sprint Planning. Their forecast should not be seen as a solid commitment, and it should be understood that forecasts can be wrong (although it's still valid to ask why a particular forecast was not accurate). Story points should only be assigned by the Development Team.

The Product Owner may use estimates and other feedback from the Development Team as an indicator when prioritizing the Product Backlog, but beyond that, Story Points aren't intended for any other purpose.

Assuming story points are respected in this way, the Development Team shouldn't feel it needs to rely 100% on them for its forecast. It can then count the total points value of previously completed work, but use its own judgement to provide a forecast each Sprint. If more or less work is actually completed, the team can learn from this, and provide better forecasts in the future. So if a Development Team forecast it will complete stories of 1, 2, 3 and 5 points, but the 3 point story is not done during the Sprint, the Development Team knows it delivered (1+2+5 = 8) points of work, and can combine that knowledge with their judgement to make a forecast in the next Sprint(s).

2 The Development Team can monitor its own progress during the Sprint, and Story Points may be the way they choose to do this (but that's up to them, because Scrum says Development Teams should be self-organizing. They may, for example, use a burndown chart to track how far through their Sprint Backlog they are.

For the rest of the business (Product Owner, stakeholders, management etc), it would be better to look at the value that's being delivered, and assess whether the end result is good, rather than the mechanics of how many points a team puts onto the things it is delivering.

UPDATE based on your comment:

I suggest when you have stories that are not Done, they go back on to the Product Backlog, where the remaining work can be re-estimated (sometimes this will go up, e.g. the Development Team realise it's more work than they previously thought). I recommend the Development Team understand they completed stories totalling X story points, plus they did some other work which they won't measure (because it's very hard to be sure if it's 75% or 40% or 90% complete). The team should be able to take this information, accept that the velocity isn't 100% accurate and be able to make a better forecast next time. No-one outside of the Development Team should care about velocity - the value of what has been delivered should be the thing they measure.

  • The team is familier with each other for a time now and their estimations for points is pretty good. The problem was that we had an ambitious design that made us search for a better library, learn it and implement the feature (it was the US we could get) in the beginning of the theme development. The real question is if on the next sprint we will put on the TO DO list knowing we have it 75% done, give it the same pointing as original and just add more available points for the team (virtually they have the completed part of the US from the previous sprint). Is this they right way to treat it?
    – Omri
    Aug 2 '17 at 6:09

Not the answer you're looking for? Browse other questions tagged or ask your own question.