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 our system, we assign story points to all the stories at the time of grooming. 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).

Here's how we plan our sprint: During first sprint we distribute the stories and production issues based on the team member's individual capacity (e.g. 75%).

During the next sprint's planning, if we have leftover items from first sprint, then we make some adjustments e.g. if there is a story of 8 story points and developer has already spent 5 days on it in first sprint, then we reduce 3 days from developer's capacity as only 3 days worth of work is left.

I'm not sure if this is right and how this affects burndown and velocity charts, because production issues don't have story points. Also, I don't know how internal issues affects aforementioned charts.

Also, when should we have sprint reviews and what's the purpose of it?

Does anyone have any comments on our practice or suggestions on how we can improve it?

  • 1
    A story with 8 story points sounds like an epic. You must break it down more.
    – CinCout
    Commented Mar 29, 2019 at 9:38
  • Our sprint is 2 weeks long so we can manage. But this number is just for an example to explain problem
    – sunil20000
    Commented Mar 29, 2019 at 9:51
  • 1
    Anyone on the team can assume the role of 'scrum master', they need only learn the role and duties needed. A team lead or dev manager can also play that role. The problem with a dev manager playing the role is they have conflicting goals. Commented Mar 30, 2019 at 3:17
  • 1
    "For us 1 story point is 1 day (again it can't be changed)." - if this is true, why are you pretending to use story points? Why not just estimate everything in days? Commented Mar 31, 2019 at 2:59

4 Answers 4


My first suggestion would be to fix your terminology to improve communication, both internally and externally. You are using terms like "Scrum Master", "Sprint", and "Sprint Review". These are terms from Scrum. Scrum is a well-defined process framework with specific roles, responsibilities, events - it has rules and those rules are defined in the Scrum Guide. If you aren't using Scrum, you shouldn't be calling what you do Scrum and you shouldn't use the Scrum terms, since it only confuses people. Do note - it's perfectly OK to not use Scrum, or to take the good ideas from Scrum (or any other process framework or methodology) and build your own process.

Next, I'd look at your method of estimation. Going back to terminology, I would recommend that you stop calling what you are doing "story points". Like Scrum, there are commonly accepted definitions of "story points", and it's not a fixed amount of time. That said, if time estimates are working for you or you have a reason that you must use them, you should continue to use them.

When planning an iteration, I would consider three things. First, consider total team capacity. If you have specialists, work on cross-training so there's little work that must be done by a single person to enable full-team capacity estimation. When estimating, don't consider that the work will be done by an expert but an average member of the team. If the expert gets it, maybe it'll get done faster. If someone else gets it, you'll be more likely to get close to your estimate. Finally, never plan at 100% capacity. There's always overhead - vacation, unexpected leave, meetings. I'd have to find my sources, but the most productive organizations reach about 80% (using your estimation scheme, that is 4 "story points" per week of iteration per person, assuming no planned vacation or holidays) and many organizations are closer to 60-70% (3 "points" per week of iteration per person). Since a common rule of thumb is that all work should be able to be complete in an iteration, a single unit of work should be no more than 6 "points" in a two week sprint (that accounts for a capacity of about 65% per person - a pretty average organization). Be sure to consider leaving some of your capacity for production issues when planning as well - you can use historical data to figure this out.

For tracking metrics, it really doesn't matter what you do as long as you are consistent. If you don't estimate production issues, you will likely see a pause in burndown as one or more people stop working on estimated, planned issues and work on production issues. If you do estimate production issues, your remaining work will increase and then burndown as work progresses. In either case, I would not update the planned burndown line. My personal preference is to estimate nearly all work - new functionality, modified functionality, bugs against production. The only thing I don't estimate is if work needs to be redone (as an example - work is finished in development but bugs are found by an independent tester - even if those bugs are logged in a tracking system, I would not estimate them unless the bugs were released to production). I would also recommend not giving a default value for production issues, but having the team attempt to come up with a reasonable estimate for each and every one.

For reestimating, again, it doesn't matter as long as you are consistent. My recommendation is to never reestimate. If work was not completed in one iteration, it retains its original estimate for the purposes of planning the next iteration. It's common in project management to only award "credit" for completion to done tasks. In some cases, a small percentage is awarded for started tasks. It's often incredibly difficult to tell how much actual progress has been made - if you think you have a fix, testing could reveal that another problem was introduced.

At the end of every iteration, you should be holding two types of events. The first, what Scrum calls a "Sprint Review" is product or service focused. You look at what you've accomplished with key stakeholders and discuss not only what you accomplished in the iteration, but what your next goals should be for the next iteration. The second is an internal reflection on how the team is working to find ways of improving the interactions between the team and stakeholders, between members of the team, or ways to improve the way of working (the processes, methods, and tools the team uses).

I would also start looking into why you can't change things like having one of the developers play the role of a facilitator and coach or why you must estimate in time rather than some other unit. I would highly recommend that most organizations have someone dedicated to understanding and improving processes, methods, and practices of engineering teams. This person should understand the environment in which the team and organization operates and various methods and can coach both the organization and the team on a path of continuous process improvement.

  • Thanks for the reply. We actually consider 75% capacity of a team member also we have tried but management is not ready to hire a dedicated SM. Regarding terms I used, actually I thought it's better to put these so that people can relate it better. I understand what you said but still not able to find solution for my problems. Can you please explain specific to my issues.
    – sunil20000
    Commented Mar 29, 2019 at 10:28
  • @sunil20000 Sorry about that - accidentally killed two paragraphs when I was cleaning up. I think those are the two that you are looking for. The other thing I will say if that if you consider your team members at 75% capacity, you are only leaving (in a best-in-class organization) 5% capacity for production issues. That is 0 days (it's roughly 2 hours). You really should be using historical data to figure out how many hours that you need to allocate for production issues as well as improving quality to prevent production issues that can't wait a week or two for inclusion in a plan.
    – Thomas Owens
    Commented Mar 29, 2019 at 10:43
  • we actually divide stories and production bug together based on the priority. And I think movie incomplete item to next sprint is good idea with it's original estimate, so that we can spend time on internal issue if QA finds any. But suppose if we move whole 8 days to next sprint and in next sprint dev completes this iten in 3-4 days and what should we do for remaining time. As planning is already done and if we pick new items from backlog then this will disturb our burndown also once sprint is started then JIRA velocity graph doesn't reflect items added after that.
    – sunil20000
    Commented Mar 29, 2019 at 11:02
  • @sunil20000 Why are you basing your process on a burndown chart? If you burn down to 0, absolutely pull in new work. Just make sure that you're reasonably confident that it will be a priority to be worked on and delivered in the next iteration.
    – Thomas Owens
    Commented Mar 29, 2019 at 11:05
  • 1
    @sunil20000 Those aren't the only options. If an individual finishes a piece of work, they can pick a new item from the iteration's backlog if one exists, pick the top item from an ordered product backlog, or help someone else complete their work. Typically, a team makes commitments to completing a body of work, not individuals. I believe that the correct order for choosing new work would be to first choose from either the iteration backlog or help someone else with their work, and only then bring in new work to the iteration.
    – Thomas Owens
    Commented Mar 29, 2019 at 13:13

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

This is not against scrum. That's a misconception. Some agile founders have even advocated for the SM duties to rotate through members of the team.

but it can't be changed.

This is against scrum. The whole point of the retrospective is to reevaluate and change the process into something that works for the team. No one on the team should be thinking "Well it just has to be this way". No. It either works or it doesn't. Don't accept things that don't work.

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).

See my previous response. Points and time are only related through velocity measurements. This is meant to drift as data is gathered and forecast a schedule that will not overload the team. It's not to be used to push developers to do more work. Letting developers even think 1 point = 1 day defeats the system. Points are closer to the gold stars your teacher gave you when you were a kid.

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.

Stories are supposed to fit inside sprints. Only epics are supposed to span sprints. This should have been broken down further. If this is happening something has already gone wrong.

Of course that doesn't keep incomplete stories from happening. Sometimes schedules slip. The healthy thing to do is reevaluate the work at the start of the sprint. You have met the enemy and your plan has died. Don't fiddle with developer availability hours trying to prop up the old plan. Make a new plan knowing what you know now.


As Thomas correctly stated, your process isn't the least bit related to Scrum.

I can offer 2 approaches to improve your process:

  1. Take any existing methodology (like Scrum, for example), and try to implement it. Only by actually implementing it will you really learn why any methodology does things in certain ways. To implement an existing methodology, you'll either need very experienced management, or you'll have to hire professional trainers.

or, alternatively:

  1. Deconstruct the methodologies you know about to their basics, and make sure your homemade methodology covers these basics. These basics are things like estimation, goals, process improvement, visibility, planning, communication, etc

As you can probably tell, 2) is harder because it requires you to learn many methodologies while 1) only requires one. 2) can be easier if the company is very small and many employees are already familiar with many methodologies - this would be the case in some startups with very experienced staff.

  • 1
    I agree with this. I wouldn't recommend 2 unless you brought in an expert on methodologies and practices who also knows about or could learn about any company, contractual, or regulatory requirements. It's much easier to start with 1, identify things that don't work (after giving them a chance to settle - process changes aren't effective immediately), and then research and implement specific solutions to specific problems.
    – Thomas Owens
    Commented Mar 29, 2019 at 15:42

There is one main thing which I think will solve your issues.

  • Break your stories up into Task's and dont pre-assign Tasks to developers
  • Tasks should not be longer than 1 day

Agile works best with very clear requirements for small simple jobs. If you can make your sprint consist of lots of little well defined jobs then you will zoom through them and any half completed ones at the end can be moved into the following sprint without affecting it more than 1 day.

You simply don't have any long tasks which roll over multiple sprints

Of course it's much easier to say than do. You can spend more time in sprint planning, discussing the implementation of stories. Don't worry too much about getting the specs 100% correct, just implement what you think will work and add more stories in the next sprint to change it if it doesn't.

If you have a bug in production obviously no-one know what the cause is or how to fix it until they have taken a look. But you will benefit from a standard approach to live issues that will enable you apply an agile approach to the fix

  1. Roll back the production version to the last known good version
  2. Make a repeatable automated test for the bug in dev
  3. Plan a possible fix story
  4. Develop Tasks from the story during the sprint
  5. Test in dev with your automated test
  6. Release fixed version.

Each of these tasks is well defined and is either short or can be split up into smaller tasks. Because they are well defined any developer can pick up any task, which means lots of people can all jump on the same problem and contribute.


suppose there was a story of 8 story points and developer has already spent 5 days on it in previous sprint

This situation can not occur if the story is split into 8 1 day tasks. The worst you can get is a mis recording of half a days work when you pull a half completed task from one sprint into the next

not sure how this is gonna effect burndown chart and velocity chart because production issues doesn't have story points

Production issues should have points and if you follow my suggestion for dealing with them you will be able to do planning and estimation as with other tasks

  • thank you for the reply but can you please elaborate a bit more because I couldn't relate this to my issues.
    – sunil20000
    Commented Mar 29, 2019 at 11:07
  • we have tried splitting our work inot small time frames like 1 day or 2 days work but in most of the scenarios this didn't work. So we have no option but going with big points. And 8 is just a number to explain my issue.
    – sunil20000
    Commented Mar 29, 2019 at 12:26
  • 2
    my advice is to try that again. but harder
    – Ewan
    Commented Mar 29, 2019 at 12:27
  • This answer clearly explains that splitting work into smaller, more manageable pieces is the solution to many of the estimation challenges, and to the problem of stories not being completed in a sprint. The other challenge mentioned was unexpected work. This answer clearly addresses how to triage and plan work. The whole point of sprints is that developers are allowed to finished planned tasks. Commented Mar 30, 2019 at 3:13
  • 1
    @ChuckCottrill You are right that not workign as a team can be a problem too, but I wanted to keep my answer short and focused on just a couple of key things
    – Ewan
    Commented Mar 30, 2019 at 10:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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