How to better use Story Points in our teams?

Question

I have several development teams that moved from hours to Story points 6 months ago. Since then, we have experienced several issues with using Story Points, and I hope you can help me and us:

1. When using hours estimations, we could have looked back on each issue and tell whether we put too much effort on it, and what is the current situation of this issue within the sprint. Moving to Story Points doesn't allow us such granulation, and we can't trace back the effort we put on an issue with X Story Points. Is this the nominal state? How do we compensate on this lack of data?

2. As mentioned, when trying to make sprints close successfully, we would look in every Daily Stand-Up on our issues, time reported VS time remaining, and could determine how much time to put, whether we need to stay late or whatever... Now, we feel that within the sprint we have no knowledge on every issue, and the team leader that wants to push his team doesn't know how to do it.

3. Obviously, not all issues are done in a certain sprint. But now in the next sprint, as we don't change the Story Points estimations - how do we know how much of an issue is remaining? It seems that we need to know it in order to add the appropriate amount of other issues to the sprint to fit the team's capacity.

4. Is there a certain practice to combine the use of Story Points for effort estimation and hours for the sprint management?

Answer 1

(1) Besides using Story points for estimation, you can still track the time spend on each issue. Nevertheless, Story points are for estimating complexity and not time. So often 1 story point is used for stories that are very similar to the ones that have been done before and where the team knows exactly how to do it. No matter if it is a tiny change or a new feature involving lots of code. The current situation of this issue in the sprint should still be accessible because in the Daily the developer working on it can usually give an estimate, how much of this issue is done so far.

(2) Usually, a team should not put in extra hours in order to achieve the sprint goal. The team should work at a pace that it can keep up in the long term. If you have e.g. a two weeks sprint, the issues / user stories should be in a size that each developer can tackle a bunch of them and each of them should in the ideal case not take longer than one or maybe a few days. This way you can pretty easily track the sprint progress by comparing what percentage of the user stories is done to the percentage of time that passed in the sprint. About the open issues, the developers can give an estimate in the Daily, how much work is left. So, I don't know about your user stories / issues but maybe one way to go is to cut them into smaller chunks / user stories and by that improve transparency and traceability.

(3) The goal in Scrum should always be to close all tasks in the sprint backlog. It might happen that sometimes one or two tasks cannot be closed but it should not be the case too often. If a task does not get closed in the sprint, it is re-estimated and taken back to the product backlog at the end of the sprint. Usually, it then gets taken directly to the next sprint.

(4) After each sprint, you can calculate the velocity of your team by dividing the number of story points achieved within the sprint by the number of developer days in the sprint. This velocity (usually averaged over the last few sprints) can then be taken as guidance on how many story points to take to the next sprint. Nevertheless, in the sprint planning, you should not blindly follow this but take into account if the stories are big or small, etc.