Need help for sprint planning when tasks are not done in previous sprint
In our team we don't have dedicated Scrum Master so one of the developer is playing the role of SM. I know this is wrong but it can't be changed.
In out system, we assign story points to all the stories at the time of grooming and Production issues don't have story points but we ASSUME it's 3 story point. For us 1 story point is 1 day (again it can't be changed).
How we plan our sprint, in first sprint based on the team member's individual capacity we distribute the stories and production issues. Problem comes in next sprint planning when we have not-completed items from previous sprint. Then what we do, suppose there was a story of 8 story points and developer has already spent 5 days on it in previous sprint. Then, in the planning of next sprint what we do, we reduce 3 days from developer's capacity as only 3 days work is left.
I'm not sure this is right and not sure how this is gonna effect burndown chart and velocity chart because production issues doesn't have story points. Also, when we get internal issues, how they affect above charts.
Another confusion is when should we have sprint review and what is the exact purpose it solves.
Anyone has any suggestion or comment about our practice and how can we improve it.
The purpose of estimation is to help a Development Team to figure out how much work it can take on. The assumption that certain types of work equate to 3 points would have to be backed up by evidence, if team estimates are to be fit for purpose. If the team are not completing work by the end of the Sprint, clearly something is wrong with the forecast being made.
I’d suggest studying the Scrum Guide to better understand how the framework ought to be implemented, including reviews and their purpose. You can also check your other assumptions, such as any constraints regarding who can be a Scrum Master.
First of all, there is nothing wrong with the role of scrum master being occupied by a member of the development team.
My first question would be "why do you even use story points?"
If your "story points" are a fixed unit that equals approximatly 1 day of work... why use story points at all? Story points are a tool and using a tool without asking yourself why can easily lead to "zombie scrums" where you just go through the motion not really understanding why. This will usually bring very little value to the team... So the first thing I would do is to challenge you to rethink how you estimate tasks.
Now on to your next question of how to handle workload with tasks that carry over from sprint to sprint... I think such a task would need to be re-evaluated in the context of the work accomplished, the work remaining and whatever was discovered by actually starting that task. For example, it's entirely possible that a task you thought would take 5 days ends up much harder and you could discovered along the way that there is no way it can be done under your initial estimates.
When you ask "When should we have a sprint review and what are it's function" it raises a HUGE red flag for me. It again tells me that you are going through the motion of scrum for some obscure reason without asking yourself why you're doing it and without even knowing what are the goals and benefits you will get from it.
As mentionned by Ian, I strongly recommend you read the Scrum Guide before doing anything else.
Sunil,
Who is advocating the use of Story Points in this manner, and why?
Story Points should be used as a Relative Estimating metric, not as a representation of time. If this is how it is currently being misused in your organization, why the extra layer of translation? Why don't you just estimate in person-days, and be done with it?
*** Please note, I'm not at all advocating for time-based estimation, but pointing out the re-labeling of time increments as Story Points in the example presented by Sunil ***
Then what we do, suppose there was a story of 8 story points and developer has already spent 5 days on it in previous sprint. Then, in the planning of next sprint what we do, we reduce 3 days from developer's capacity as only 3 days work is left.
If you are looking for a quick answer to mechanically follow: yes incomplete items are re-estimated and put back into the Product Backlog for Product Owner to decide what to do next.
The logic behind it is explained above.