Frequently Asked Questions

Our Professional Scrum Trainers have worked to gather many of the questions that are asked by their students, the Scrum.org Forum and other places to provide answers to your Frequently Asked Questions about Scrum. 

• How do we handle spill-over between Sprints?
  • There is no spill-over (or carry-over) of work from one Sprint to the next in Scrum: the concept does not exist. The right thing to do with unfinished work is for the Developers to re-estimate it on the Product Backlog, and then allow the Product Owner to order it appropriately. Bear in mind that business conditions can change very rapidly.
• How do we do a ticket that’s too big to fit in a Sprint?
  • The leap-of-faith represented by that item is too great. Rethink it in terms of the smallest useful experiments which need to be done to validate any assumptions being made about the item’s value.
• Who decides when to release?
  • The moment something is Done, an Increment is born and the imperative is to release it. Empiricism should not be put in delay. The Developers on the Scrum Team are accountable for meeting the Definition of Done and thus for ensuring work is of usable quality. A Product Owner can stop an increment from being used if it is inappropriate for current business conditions.
• How do we measure the success of a team?
  • A Scrum Team determines its success by providing at least one Done Increment of useful working Product each and every Sprint.
• How do I facilitate a Retrospective?
  • Encourage divergence and convergence amongst participants, expect frustration, and help them to navigate it through focus Look for at least one improvement to the team’s implementation of Scrum, preferably for implementation in the next Sprint so adaptation is timely. The right participant to facilitate an Event can be the one who sees it needs doing.
• How do you prepare for a Demo?
  • Only work that is Done ought to be shown to stakeholders. The important thing is to then update the Product Backlog with any work that remains to be Done. A Sprint Review may not require a demonstration at all: the Sprint Backlog could be used as a checklist, and the Product Backlog updated.
• What KPIs do we use?
  • The primary measure of progress is having Done increments of working product, of which at least one must be produced every Sprint. The Developers on the Scrum Team should monitor their progress towards this, using whatever techniques they deem appropriate. These might include burn-up and burn-down charts and velocity or throughput measures. KPIs for business purposes are suggested and outlined in the Evidence Based Management framework.
• How do we plan ahead when a QA Sprint lags behind a Development Sprint?
  • Every Sprint ought to result in at least one Done Increment of immediate usable quality. Focus is needed to ensure that all development work, including quality assurance, is completed each Sprint. Consider reducing work in progress accordingly, and ensure that the Developers have all skills needed to meet the Definition of Done for the Product.
• Who creates the Definition of Done?
  • The Scrum Team works to craft a Definition of Done which assures the usable quality of the Product, which the Developers will then be accountable for meeting. Organizational standards may be used used as a starting point for determining the quality needed.
• How do we account for partly completed stories when reporting our velocity?
  • Velocity is the rate at which work is Done, not partly done. Any work which is not yet completed ought to be re-estimated by the Developers on the Product Backlog. The Product Owner should then order and organize the work appropriately, taking into account the latest business conditions.
• How do I map story points to hours?
  • The only purpose of estimation in Scrum is so the Developers can get their arms around how much work they can do in a Sprint. They will consider not just time, but other factors such as effort and complexity.
• Can we change the Sprint Goal?
  • The Sprint Goal is a commitment made by the Developers. They may change the forecast of work on the Sprint Backlog, as more is learned during a Sprint, to ensure it is satisfied. The Sprint Goal cannot change during a Sprint, but if it becomes obsolete the Product Owner may cancel the Sprint itself given that its achievement is no longer valuable.
• Who assigns tasks to the Developers?
  • The Developers themselves decide who does what during a Sprint in order to meet their Sprint Goal commitment. They have a formal opportunity each day, in the Daily Scrum, to replan their work on the Sprint Backlog to better meet the Sprint Goal.
• How do we tell management when we will deliver the project?
  • The most important project in Scrum is the Sprint, since this allows empiricism to be established and maintained. Other projects may exist, but forecasts for their completion must be evidenced by work completed each Sprint.
• How can story points not relate to time?
  • The Developers may estimate work in any way they see fit, as long as it helps them figure out how much work they can take on and complete in a Sprint. As such they may not consider just time, but also complexity, effort, and other factors.
• Who moves tickets to the Sprint Backlog?    
  • The Developers manage the Sprint Backlog: it's their forecast of work for meeting the Sprint Goal they've committed to. They may remove, add, or modify this work so the Sprint Goal will be better achieved. They should collaborate with the Product Owner when changing Product Backlog items. No work should ever be planned into the Sprint Backlog which would put either the Sprint Goal or the Definition of Done at risk.
• Can we combine the Sprint Review and the Sprint Retrospective?    
  • The Sprint Review and Sprint Retrospective are separate time-boxed events, each with a specific focus. There is no rule against conducting them sequentially. The Sprint Retrospective bookends the Sprint and hence will always be the final activity. Product stakeholders may be invited to the Sprint Review if their input is thought useful, but they would not attend the Scrum Team's Sprint Retrospective.
• What are the inputs and outputs of the Scrum ceremonies?    
  • There are no ceremonies in Scrum but there are events, each of which is a formal opportunity to inspect and adapt something. Sprint Planning requires a Product Goal and enough work that is ready to choose from, a Definition of Done, and an understanding of capacity. A Sprint Goal is agreed, along with a forecast of work in the Sprint Backlog for meeting it. In the Daily Scrum the Developers inspects the current state of the Sprint Backlog and their progress to the Sprint Goal, and update their plan for the next working day. The Sprint Review considers the work that has been Done and remains to be Done, and the Product Backlog is then updated. The Sprint Retrospective considers everything to do with the Scrum Team's way-of-working with regards to individuals, interactions, processes, tools, and the Definition of Done, and results in at least one improvement in team effectiveness.
• How do we reopen user stories?    
  • Once a Product Backlog item has been Done, it no longer represents work on the Product Backlog. Should any new work be discovered, new Product Backlog items may then be created, refined, and selected in future Sprint Planning events. Remedial work for an Increment of insufficient quality ought to be accounted for on the Product Backlog, and the Definition of Done improved.
• I’m a Product Owner – do I write the user stories?    
  • The Product Backlog must always tell the truth about the work that is currently believed to remain for the Product over its lifetime. The Product Owner is accountable for ensuring that the Product Backlog provides this transparency over Product value, but he or she does not have to author, order, or organize any Product Backlog items. The Product Owner may delegate such responsibilities to others if they are agreeable, whether they be Developers, stakeholders or the office cleaner, but the Product Owner would remain accountable for whether or not Product value is then optimized.
• How do I prioritize the Product Backlog    
  • A Product Owner will order and organize the Product Backlog taking into account many things, of which priority is just one. Other things they consider include dependencies (business, technical, workflow, human), value, risk, and many other factors. They'll observe the rate at which work is being Done, and use this to inform themselves about how the backlog will be arranged so value delivery is optimized over time, bearing in mind that each Sprint is a learning experiment. A Product Owner can delegate the responsibilities of backlog management to someone else if they are agreeable, but ultimately the Product Owner remains accountable for value delivery outcomes.
• How do we do V-Model testing in Scrum?    
  • The entire point of Scrum is to produce a Done and immediately usable Increment at least once every Sprint. The Developers are accountable for ensuring the quality of each Increment. Anyone whose industry is needed for this is a Developer, including those doing testing. If the Developers believe a V Model helps them to assure a Done level of quality, then they may use it each Sprint. On the other hand they may prefer to apply focus and limit their work in progress, so individual items from the Product Backlog are built and tested early and often. This could help them to manage risk more effectively than a V Model approach.
• How do we estimate spikes?    
  • The term "spike" usually refers to an investigation, by the Developers, into the nature and extent of the work that will probably be required to complete something. They may conduct a spike investigation to help them determine feasibility, or to estimate how much time, complexity, and effort is likely to be involved. As such, a spike ought to be seen as a Product Backlog refinement activity. It isn't something that would or could be estimated at all, but will be allowed for in the time a Scrum Team reserves for refinement activities. A spike might reasonably be conducted as a time-boxed activity.
• Does BA or UX work go on the backlog?    
  • Whether or not certain work goes on a Product Backlog depends upon the Product Owner's ability to account for its value to stakeholders, and to meaningfully order that work in relation to existing Product Backlog items. The work a Business Analyst or User Experience specialist performs may not be of such clear value, but it may well enable other demonstrably valuable pieces of work to be completed. As such, BA and UX work might not necessarily be accounted for and managed on a Product Backlog. Instead, it might be something the Developers would undertake as part of their Definition of Done, or to ensure that work is refined and made ready for Sprint Planning.
• Should we track the Product Owner’s tasks in issue tracking software (Jira, GitHub, etc.)?   
  •  If the Product Owner is also a developer, then it would be reasonable for the Developers to collectively monitor that work. He or she would then share in the Developers' commitments to create Done Increments that meet a Sprint Goal. The Developers should establish transparency over their commitments, and to inspect and adapt the work they do to meet them.
• How do we write technical stories in issue tracking software ?    
  • The Product Backlog should tell the truth about the work currently believed to remain for the Product over its lifetime. If technical work can be meaningfully ordered and organized as separate Product Backlog items, then it need not tell a story at all. On the other hand if there is no valuable "story" to tell, then a Product Owner might not be expected to manage it as discrete items on the Product Backlog. Despite this reduced transparency, it would still be up to the Developers to ensure that the work is undertaken and that technical debt is kept under control. They may incorporate it into the Definition of Done for the Increment, and reflect the time, effort, and complexity needed to complete it in their estimates of other future work.
• What do I do if a Developer is underperforming?    
  • The Developers are collectively accountable for the work that they do, and for meeting their joint Sprint Goal commitment. Notice that the role is Developers (plural) and not Developer. This means that if there is any policing to be done, the Developers must police themselves. The best thing is to establish transparency over the situation, so a consensus view of reality is achieved, and to assume good intent. The Sprint Retrospective presents a formal opportunity each Sprint for the Scrum Team to inspect and adapt its way-of-working, and to identify meaningful improvements. Ultimately, a team should be able to decide who becomes or remains a member, and when.
• How do I manage the Daily Scrum?    
  • The Daily Scrum is a formal opportunity for the Developers to stand aside from their work, for a maximum of 15 minutes, and to come up with a plan for the next working day. Only the Developers need to be there: anyone else should be trying to make themselves redundant from this event. The Developers should decide for themselves how best to manage their Daily Scrum. They may "walk the board" for example, reading it from right to left, challenging impeded work and prioritizing completion before starting anything new. If they wish they may take it in tums to faciliate, or choose one amongst their number. Ideally, the right person to facilitate something is the first one who sees that it needs doing.
• How do we use stretch goals?    
  • Scrum is a commitment based framework. As such, a goal must a realistic and achievable commitment, not a stretch. Commitments are either met or they aren't. Sufficient contingency ought therefore to be planned into each Sprint to allow commitments to be met. Contingency is found in scope: not all of the work planned into a Sprint Backlog may be essential for meeting a Sprint Goal. If a Sprint Goal is met too easily, an opportunity is presented for the Developers to rethink their capacity, and to be more ambitious when making future commitments.
• Do I need to understand the product as a Scrum Master?    
  • It would be better for a Scrum Master to understand people, since that is where most of the risk and uncertainty lies when building complex products. The Product Owner is accountable for ensuring that other team members understand the Product well enough to deliver value, while the Developers are accountable for ensuring the work is Done to a usable level of quality.  The Scrum Master should understand enough about a Product to facilitate progress so these accountabilities are met.
• How do I become a Scrum Master with no experience?    
  • Think about the servant leadership you can provide and exemplify to others right now. A Scrum Master may adopt different stances at different times. These stances include being a coach, a teacher, a facilitator, and a guiding light about what the Scrum Framework really means. Remember the problems you have helped people to overcome, including those occasions when you were invisibly present, and regardless of whether or not you were thought of as a Scrum Master at all.
• How do we allow for client testing?    
  • Anyone whose labor and industry is needed to ensure that each Increment is of usable quality is a Developer, and therefore a member of the Scrum Team. If clients are doing testing, then they are Developers whether they realize it or not. This is the truth which is being exposed, and the Increment will not be Done until they have finished their work. The Developers must plan to complete at least one Done Increment each and every Sprint.
• Who fixes broken tests?    
  • The best way to inspect and adapt is as closely as possible to the time and place of work being carried out. If the quality of the Increment becomes compromised, the right developer to provide remedy should the first who recognizes the problem, which ought to be whoever made the offending change.
• We have no Product Owner. What do we do?   
  •  Find out who is accountable for the value of any work currently being undertaken. This might involve following project money or operational expenditure, for example, and it may lead to people who do not yet appreciate the Product Ownership role. A Product Owner can delegate their responsibilities -- the doing of their job -- to somebody else if they agree. However, the Product Owner would remain accountable for outcomes regarding Product value.
• How do we do PI Planning?    
  • Make sure that a Done, finished Increment of immediately usable quality is produced each and every Sprint. This must include all necessary integration and testing across all impacted products. The empirical feedback obtained from the usage of finished increments informs future planning activities, with multiple opportunities to inspect and adapt. It's important to reduce the leap-of-faith taken before planned outcomes are actually obtained.
• Should a Scrum Master be technical?   
  • A Scrum Master should be technical enough to be assured that if the Developers were to follow their Sprint plan, at least one Done Increment of immediately usable quality would be produced, and the Sprint Goal would be met. A Scrum Master would not do any of the work themselves unless he or she is also one of the Developers.
• How do we stop stakeholders from adding tickets to issue tracking software?    
  • A Product Owner can delegate the authoring of Product Backlog items to others, including stakeholders, if they are amenable. Accountability for the state of the Product Backlog nevertheless rests with the Product Owner. If the Product Owner does not wish for others to modify the Product Backlog, then he or she ought to secure it against unwarranted change. The Scrum Master may also educate stakeholders about which behaviors are helpful and which are unhelpful.
• How do we plan with the test team?    
  • Anyone whose labor and industry is needed to ensure that each Increment is of usable quality is a Developer, and therefore a member of the Scrum Team. Testers are Developers whether they realize it or not. This is the truth which is being exposed, and the Increment will not be Done until they have finished their work. The Developers must plan to complete at least one Done Increment each and every Sprint.
• Can we change scope in the middle of a Sprint?    
  • Yes. No backlog is ever fixed. The work on a Product Backlog enables discussions about valuable Sprint Goals which ought to be met. The items on a Sprint Backlog are a forecast of the work needed to meet a Sprint Goal.
• How do we estimate bugs?    
  • If a defect is identified in work being done this Sprint, then it does not need to be estimated. The fixing of the defect just represents work in progress, and the Developers ought to replan their work accordingly. It may be necessary to revise other work in the Sprint Backlog so the Sprint Goal is not put at risk. If a defect is identified in work that was undertaken in previous Sprints, then it may be estimated and accounted for in the same way as any other Product Backlog item. Whenever defects of any kind arise at any point, the Developers ought to challenge and improve their Definition of Done, so issues do not recur and better quality is assured in the future.
• How do we decide the story points?    
  • Here's one way to do relative estimation. Put up six headings: 1, 2, 3, 5, 8, 13, 20. Choose any one item randomly from the Product Backlog. Call it a 5. Take another and decide if it is the same time, effort, and complexity, or more or less and if so by how much. Then do the same for the next item and so on. Eventually a bell curve will emerge, the deepest part of which represents the median. Recalibrate the headings if necessary so the median now lies at 5.
• Can we fix bugs in a Sprint?   
  • If a defect is identified in work being done this Sprint, then it represents ongoing work in progress, and it must be fixed. If a defect is identified in work that was undertaken in previous Sprints, then it may be remedied this Sprint if doing so does not put the Sprint Goal at risk. Whenever defects of any kind arise at any point, the Developers ought to challenge and improve their Definition of Done, so issues do not recur and better quality is assured in the future.
• Can the Scrum Master and Product Owner also be Developers?    
  • Yes. There is no prescription against someone holding multiple accountabilities in Scrum. However, this does not mean that it is always reasonable for someone to do so. Each situation must be considered in context and on its own merits, taking into account the time available, requisite skills, any potential conflict of interest, and other factors.
• What do we do if not all of our Sprint Goals are met?    
  • Each Sprint must have exactly one Sprint Goal. It is a commitment that makes the work in the Sprint Backlog coherent, and more than just the sum of its parts. The Sprint Goal gives the Developers a reason to work together this Sprint, rather than on separate initiatives. and mitigates a significant risk or uncertainty in a complex challenge.
• Do we need to finish all our stories in a Sprint?    
  • It's important to commit to a goal and not to a forecast of work. A Sprint Backlog is a forecast of the work the Developers believe they need to do in order to meet their Sprint Goal commitment. That work can be inspected and adapted at any time, and will be revised throughout the Sprint so the Sprint Goal might be better achieved. Some, all, or none of the work originally planned may be completed, but the Sprint Goal must remain intact and be satisfied.