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 (i.e. 75% only) 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.

  • 2
    It might be a good idea to give your Scrum Master a training course. There are a lot of issues that probably need to be addressed. – nvoigt Mar 29 at 12:31
  • 1
    Tangentially, may I suggest you call your story points days instead? Might as well call it what it is. No good reason to apply a unit label for something you aren't using. – Daniel Mar 29 at 13:00
  • @Daniel Actually everyone knows about these term so thought of using them so that people can relate easily. – sunil20000 Mar 29 at 13:05
  • @nvoigt actually I searched multiple forums regarding this issue but couldn't find solution. So, I believe SM training won't be enough, need someone who has good experience in this and has faced the same problem. – sunil20000 Mar 29 at 13:06

There are two answers to this: the scrum answer and the deeper answer to the questions under the surface.

First, the scrum answer on carry-over work. At the end of a sprint, all items go back to the product backlog. There is, of course, strong motivation to pull them into the next sprint to finish, but it isn't assumed. Sometimes in the past 2 weeks other very important items came up that are more important than finishing that item. Also, carry over work is a light antipattern in Scrum. What I mean by this is that we do want to get to a complete product increment each sprint, but we also know that a team doing challenging work won't all the time. The rule of thumb Mike Cohn uses is "100% of the work done 80% of the time".

Ok, now the answer to why you're struggling. I don't mean to berate you when I say this, but there are a lot of misused practices in there and that is causing the parts of the Scrum framework not to support each other properly. First, Scrum looks to past sprints for the team's capacity. If in the last 3 or 4 sprints you completed an average of 25 man-days of work, then you take on around 25 man-days of work in the next sprint. Also, the team commits to a body of work, not individuals. Also, production issues are often open-ended, so unless you already know the problem and have an idea of what the solution may be, estimating them isn't often helpful. Usually, we want to instead time-box them, which sets an outer limit on how long you are willing to work on them before it impacts the overall sprint. Of course, some are very important, so if you reach your timebox, you don't just drop it, you regroup with the team and discuss how to move forward next. Usually, if you extend the timebox, you are also agreeing what work you will kick out of the sprint to make room.

This kind of capacity planning will give you more control over your pace of work and after a few sprints, you can get to that Mike Cohn rule I mentioned before. Once you are there, you can get into the really interesting bits of Scrum. Scrum looks at the team as a whole, not individuals. By fielding work as a team (sometimes this means things like pairing, group sessions, divide and conquer of individual tasks, etc) many teams find synergies allowing the overall team to be much more productive than the sum of the individuals. (I know synergy has become a terrible buzzword, but it's actually a real thing too)

For the charts, in Scrum, remember that those charts aren't the goal. Burndown charts, CFDs, velocity charts, they're like meters on a dashboard. They just tell you information. Carry-over work often leaves these charts looking erratic - which just tells you that the team is delivering the work in an erratic way. As they are able to smooth out the delivery of work, the charts smooth out.

On the review, in Scrum, the review happens at the end of the sprint and stakeholders and users give feedback on the work that was done in the sprint so the team has a better idea of what to do next. This may be another thing that is out of alignment. One of the most important things that Scrum lets you do in each sprint is learn. If the feedback from sprint reviews isn't changing your understanding of the work you are doing and influencing where you put your effort next, you aren't getting the primary value out of scrum. If your work doesn't need that (you work in a service center where you are simply doing tasks first come-first serve or in priority order), then Scrum may actually be the wrong framework to use. Not that it won't work at all, but it's like driving in a screw with a hammer.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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