Q&A | A Visually Rich Overview of the Scrum Framework Webinar January 13, 2016

Integration of Scrum and Comparison with Other Frameworks and Processes

• Should we limit WIP in Scrum like in Kanban? o Yes, we do this every time we plan a sprint. The development team pulls in a limited number of product backlog items based on its capacity to do work. During sprint execution the team always limits its work. During the webinar, I offered a strategy of “swarm to the fewest” in answer to the question of how many items should a development team work on at one time. This is also a WIP limit.

• Self-­Organizing implies that all participants have knowledge of Scrum/Agile. What if your organization is beginning to use Scrum/Agile but doesn't have a lot of experience yet? What is the best way to build the development team?

o Nothing will prove more effective than starting your first sprint, learning from the experience, and then inspecting and adapting. My biased opinion is that people will get a leveraged head start if they read books like Essential Scrum (which is why I wrote it) or attend a training class (like a Certified ScrumMaster® class).

• Isn't the design of the product backlog really a waterfall project (Charter, Planning, Scope, Budget, Schedule/Time, Quality, Risk, Procurement, Close)?

o Not at all. The “grooming” or “refinement” of the product backlog is an ongoing, emergent process and most certainly doesn’t following a phased-­based sequential approach. I am thinking that perhaps you want to ask a different question than the one you wrote, but the product backlog is an artifact for managing scope and change.

• Can Scrum be implemented within BAU (Business as Usual) teams? o All the time! You can use Scrum for maintenance of existing systems as well as the development of new systems or products. An important question you will want to ask is: “How interrupt-­driven is the BAU team?” If you can reasonably plan their BAU work, then Scrum is likely a good fit.

• Are you aware of companies effectively using Scrum for SAP implementations? Any tips to make this and other ERP efforts effective?

o I have met people at conferences who told me they have used Scrum for SAP implementations. I personally have not worked on such a project. However, I have used Scrum with other COTS

products. My experience is that it works just fine. Most of the items in the product backlog tend to be enhancement or customization items (instead of new feature development), but that is the nature of the work!

• You mentioned that one shouldn't create a mini-­waterfall during a sprint, but that Scrum doesn't dictate how work should be performed. How can one avoid a mini-­waterfall if feature work has stages that lead into one another? Are there any development techniques that Scrum would suggest that would help a team avoid the mini-­waterfalls and meet their commitment more consistently?

o If the nature of the work that you do follows a natural sequence of steps, then that is how you will do your work. The point I was emphasizing during my presentation is the belief that the only way to do work is to follow a waterfall-­like pattern, and that is clearly not true and most of the time not a good way to sequence task-­level work during a sprint to ensure good flow (i.e., getting the job done). In terms of techniques, a good approach is to expose team members to alternative ways of flowing work (like test-­first development). Then the self-­organizing team can determine how best to organize the work to get the job done.

Done • Who should approve the sprint backlog items as done according to DoD?

o The product owner is the only person with the authority to declare an item done during a sprint.

• Can the definition of done (DoD) change from sprint to sprint? o Yes, but most of the time it stays the same. What is more likely is the DoD will evolve over time as impediments are removed. For example, the early DoD might not include performance testing because there isn’t enough performance testing resources in the company for all teams to performance test every sprint. However, when enough resources become available, teams can now performance test every sprint.

• What are the definitions of and differences between done and ready? o Ready and Done are two states of a product backlog item. The item needs to be “ready” before sprint planning, and it needs to be “done” by the end of sprint execution. This blog elaborates the idea: http://www.innolution.com/blog/definition-­of-­ready

Misc.

• Ken, what happens when, in following a SAFe model, product managers give a fixed release date and scope, teams are fixed, and expectations of high

quality are also fixed. How can teams effectively apply Agile Scrum given this approach?

o I suggest you read this blog post: http://www.innolution.com/blog/scope-­is-­the-­antifragile-­degree-­of-­freedom

• Benefit of hours estimate vs. story point estimates: If you have a team with 40 members, each person sharing "what I did yesterday/today," how do you keep the Scrum within 15 minutes?

o You can’t. So don’t have a team of 40 development team members. Remember, in Scrum we scale not by having larger development teams, but instead by replicating the Scrum team pattern (please see the Scaling with Scrum slide in the presentation).

• What’s the expected (or ideal) time period to implement outputs from the sprint retrospective meetings?

o I encourage teams to commit only to improvement actions that they can reasonably complete during the next sprint. Of course, the nature of some improvements is that they will take longer to complete than the next sprint, but the expectation is that the improvement work begins in the next sprint.

• How does one become a skilled facilitator? o For the really good ones, this is a life-­long pursuit! There are a number of excellent facilitator training programs that people can start with. I have found that great facilitators have often been the mentee of an even greater facilitator mentor. So, I would probably seek out such a mentor.

• How do you measure the performance of Scrum team members -­-­ for annual appraisals? Does Scrum framework provide any guidelines?

o I have blogged about this. Please see: http://www.innolution.com/blog/team-­performance-­measures.

• Have you ever seen any of these practices applied to a team that was not software development or technology?

o Absolutely! I have used Scrum with hardware and firmware teams. You can read about that here: http://www.innolution.com/blog/agile-­in-­a-­hardware-­firmware-­environment-­draw-­the-­cost-­of-­change-­curve. I have also used Scrum (and Kanban) with religious organizations to manage their outreach work.

You can download two presentations about that: http://www.innolution.com/resources/presentations/managing-­opportunities-­and-­work-­in-­a-­medium-­to-­large-­chabad and http://www.innolution.com/resources/presentations/managing-­opportunities-­and-­work-­in-­a-­small-­chabad I have also used Scrum with marketing and sales teams (nothing written to share about this).

• Can you give more detail on insight backlog? How do we capture them while executing the sprint?

o Here is the definition of the insight backlog: A prioritized list of previously generated insights or process improvement ideas that have not yet been acted upon. The insight backlog is generated and used during sprint retrospectives.

• How would you reach a potentially shippable product increment if there are external requirements that the tests are performed/signed-­off on the product that actually gets shipped?

o Technically, you can’t! If you can’t, within a sprint, complete all of the work that would be needed to ship, then you aren’t potentially shippable. However, as a practical matter, your Definition of Done for your team should extend as far as it can toward the potentially shippable state. You might still end up having an external testing sprint at the end. I had to deal with this once on a government / military project where the government required (via the contract) that the system be tested in the government’s environment before it could be called done.

• From your experience, if you aim for 2-­3 sprints in inventory (on product backlog) ready and for getting the AC ready and you are are defining wireframes and visuals that will be approved by the customer... what are your recommendations to speed this up?

o You might include wireframes as a part of your definition of ready. I have seen this in several companies. You are trying to find a balance when it comes to defining ready. Include too much in your definition of ready, and you will incur too much waste when you decide not do something. Don’t include enough aspects in your definition of ready and your items won’t be ready and you will make a poor commitment at sprint planning. My goal: Definition of Ready should be “good enough,” or my preferred way of saying it: “barely sufficient!”

Planning

• Why are planning poker cards 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, instead of Fibonacci numbers 1/2, 1, 2, 3, 5, 8, 13, 21, 34,,, ?

o Most planning poker cards follow Mike Cohn’s “modified” Fibonacci sequence. The sequence was modified in an attempt to avoid the illusion of being overly precise. As items get larger, we are less capable of sizing them and distinguishing small difference. So, you see 20 instead of 21, and 40 instead of 34. Planning poker is really just an exercise in binning. If you want to better understand what I mean by that, read this: http://www.innolution.com/blog/relative-­size-­estimating-­its-­just-­an-­exercise-­in-­binning

• Why is the Fibonacci series used for story point estimation? o The overall pattern has favorable characteristics. There are more numbers at the lower end of the scale where we want most of estimates to be, and the numbers spread out and get further apart when items get larger, since we have less certainty here. Powers of two would have a similar, favorable pattern (1, 2, 4, 8, 16, 32, …)

• During the sprint planning, should the development team break down the PBIs into tasks, or does that happen prior to the sprint planning? Or after?

o If the development team chooses to use tasks (they are not required to do so), then they would break down PBIs into tasks during sprint planning. Doing so earlier would generate too much task-­level inventory. You could do it after sprint planning, but most teams who use tasks view them as a way of acquiring confidence that they can complete the PBIs;; they create them during sprint planning so they can make their commitment by the end of sprint planning.

• How can the team best manage effort and time required to get PBIs to a sprint-­ready state (ex. research, design, proof of concept)?

o Having a useful definition of ready will help determine the economically sensible amount of effort to invest in getting items ready. Without knowing what constitutes ready complicates the investment decision.

• Can you talk some about release planning? o This is a lengthy topic and Scrum does not formally define release planning. I cover this topic in detail in Chapter 19 of Essential Scrum. I suggest you read that.

• When do PBI estimates get created? o During product backlog grooming. I mentioned that development team members should budget 5-­10 percent of their total capacity each sprint to assist the product owner with grooming. During this 5-­10 percent, each sprint the development team members will

spend time estimating product backlog items. Of course, some of this estimating has to occur before sprint one, and that will take place during release planning.

Product Backlog

• Is the product backlog an ordered list or a prioritized one? o I refer to it as a prioritized list. The Scrum Guide refers to it as ordered. Here is what I said about this topic in Essential Scrum: “… in 2011 there was another debate as to whether the appropriate term for describing the sequence of items in the product backlog should be prioritized (the original term) or ordered, the term used in ‘The Scrum Guide’ The argument was that prioritizing is simply one form of ordering (and, according to some, not even the most appropriate form of ordering). The issue of how to best sequence items in the product backlog, however, is influenced by many factors, and a single word may never capture the full breadth and depth of the concept. Although there may be theoretical merit to the ordered-­versus-­prioritized debate, most people (including me) use the terms interchangeably when discussing the items in the product backlog.”

• Who "owns" the grooming? Product owner or ScrumMaster? o Product owner owns the grooming process. ScrumMaster coaches and facilitates the process.

• Will PO do sizing of items in product backlog with the help of team, or are you talking about something else?

o The rule is that the people who do the work put the size estimate on the work. So, on feature teams, the product owner is typically a business person and will not do the work and, therefore, should not estimate. However, if you use component teams, then the product owner is likely a technical person and maybe a member of the development team. If the PO is on the development team, the PO would estimate (as a development team member).

• Is grooming ongoing, or is it more of a one or two sprint look-­ahead? o Yes, and yes. It is ongoing, and I always want roughly two to three sprints worth of ready PBIs in inventory in the product backlog.

• When you define your backlog items, should the "stories" with the biggest benefit have highest priority?

o That is one criterion that a product owner might use to prioritize. But, there are a number of other factors that must be considered. For example, value, cost, knowledge, risk, dependence, resource constraints, cost of delay, etc. Isn’t being a product owner fun!

• Who needs to be involved in the three different parts of grooming (defining, estimating and prioritizing)? Just the PO or the whole team?

o See my blog post on this topic: http://www.innolution.com/blog/who-­should-­attend-­scrum-­meetings

• Can the team change the order of the backlog during the grooming process? o If by team you mean the development team, then members of the development team can and should give input to the product owner that could affect prioritization. However, the product owner owns the content of the product backlog and the order of the items in the backlog, so only the product owner makes any actual changes to the product backlog.

• Who creates the backlog items, and who would split them if deemed too big for a sprint?

o In my experiences, better PBIs are written as a collaborative effort of the full Scrum team (PO, SM, and development team).

• Is it better to create the tasks when groomed, or when planned/committed? o Better to do it during sprint planning. This leverages the principle of the last responsible moment.

Roles

• You said PO should take care of ROI. Should PO be responsible for sales and marketing as well?

o I assume in most companies there are separate groups that handle these functions. That is not to say that the PO doesn’t get involved in these areas. For example, PO might go on sales calls, but I wouldn’t think of the PO as the sales person.

• We have one product owner who has to run around to three sprint planning meetings. She is never present all the way through. Any suggestions?

o If all three teams are working together on the same development effort, then do a combined sprint planning meeting with all three teams present. If they are working on different efforts, then your PO is overburdened and senior management needs to address this problem.

• Is there any role for the business analyst (BA) in Agile framework? o Sure! BAs are often members of development teams. Or the BA might be supporting the PO directly. In some organizations, they have the BA be the proxy for the real PO (not my favorite solution, but I have seen it work).

• How does a development manager fit into the sprint process? o In most organizations people on the development team still report to someone else in the organization (typically a development manager). So dev managers still have many, but not all, of their traditional management responsibilities. For more details I will refer you to Chapter 13 of Essential Scrum (titled “Managers”) where I discuss this topic in detail.

• Is it best for a SM to have a development background or a management background (PM, other...)?

o I don’t have strong preference. As long as the person who fills the role can handle the responsibilities of the role and can exhibit the characteristics of a ScrumMaster, I am good. I do think it would be an asset if the SM had working knowledge of the technologies we use as well as working knowledge of the business domain.

• In many situations, there is an expectation to be PM/ScrumMaster when management expects one person in two roles. How do you reconcile the two roles?

o The question you should be asking internally is why is there a desire to have two roles? Scrum does not call out a PM role, just a ScrumMaster role. What will the PM do that isn’t already being done by one of the other three Scrum roles? In Chapter 13 of Essential Scrum, I map standard PMI project manager responsibilities onto the three Scrum roles to show that the responsibilities didn’t go away;; they were simply distributed out to members of the Scrum team (PO, SM, and development team).

• Are you considering QA test personnel as part of the development group during a sprint? Assuming QA is considered part of development, how is the QA usually organized within a sprint?

o Yes, people with QA skills need to be members of a development team. I suggest you move away from role-­based thinking and consider the complete set of skills you will need to achieve you team’s agreed-­upon definition of done. Then, staff appropriately. The dev and QA work during a sprint should be so completely interwoven that it would be nearly impossible to separate them!

• Where do you see the resource (HR) manager of the development team fitting in Scrum? Where can they add the most value?

o I refer you to Chapter 13 of Essential Scrum where I discuss this topic in detail.

Sprint

• What is your view of pulling in items mid-­sprint? o If the team completed all of the work it agreed to get done at sprint planning and the product owner agrees, sure! Then you ask yourself why did the development team under-­commit at sprint planning. If you are referring to pulling in work to deal with a high-­priority interrupt, then you need to evaluate the economics of doing so. The rule is: No goal-­altering changes once a sprint starts. Unless, of course, the economics favor making the change.

• My company has many support services groups with which our Scrum team must interface. It's often difficult to get a potentially shippable product increment completed in one sprint. I've been coached to work on chunks of those increments on a given sprint, knowing it will take 3-­4 sprints to complete the whole end-­to-­end piece, even if that's a thin slice of the final item. That occurs because of the difficulty in building out the infrastructure. That is, these aren't phone apps. Is this an OK approach?

o It’s not unusual for a large feature to require multiple sprints to complete. I prefer to vertically slice a larger item along business boundaries rather than horizontally split an item along technical boundaries. I would also look at the dependencies on the other services groups. Perhaps part of your solution is restructuring your teams so that you have all of the people on one team to get the job done (potentially shippable).

• What occurs if all of the team members are in a sprint and an urgent matter arises;; does the sprint get interrupted to take care of the urgent matter or does the matter get added to our team's backlog for the next sprint? Is it okay at any point for the Product Owner or Scrum Master to disrupt a sprint?

o The rule in Scrum is: No goal-­altering changes to the sprint once the sprint begins. So, as a rule, you don’t interrupt a sprint, unless the economics favor doing so. Please read: http://www.innolution.com/blog/economically-­sensible-­change

• Shall we follow calendar or working days for time-­boxing? o Let’s say you are doing two-­week sprints. For most teams (like more than 95%) that means 10 calendar non-­weekend days. What if a holiday occurs during those 10 calendar non-­weekend days?

These teams would NOT extend their sprint. So, to these teams 10 days doesn’t necessarily mean 10 working days.

• How would you defend spending a long time on the frame (sprint activities) instead of doing the actual feature?

o The time spent doing planning, review, and retrospectives is value adding and needs to be done at some point. In phased-­based, sequential development (i.e., Waterfall), the planning was frontend load. What was the justification there for delaying doing ANY valuable work for a long period of time so we can put together a plan that we know is wrong? In Agile, we take the effort that would have been expended up front on a waterfall project and exert that effort in a just-­in-­time fashion when it is more valuable to do so. If someone argues not to do this work at sprint boundaries, then when are they proposing to do it? Or do they just want to eliminate it? Agile doesn’t mean we are out of the planning business!

• What is the best day of the week to start a sprint? o Depends on your team or culture. Actually I would suggest you ask a different question! When is the best time to hold the sprint review meeting? This is the most difficult meeting to schedule since it involves your stakeholders. I would pin down that meeting first and let the other meetings flow naturally around it.

• How soon after a sprint ends should the team demo a potentially shippable product to the PO/stakeholders?

o The development team should review items with the PO during sprint execution and NOT during the sprint review. The sprint review is for the stakeholders, so that is when they should see done items and provide feedback to help inspect and adapt how we move forward with the product.

• Should unit and UAT testing be included in a sprint or is that done after? o Would you call your items done (potentially shippable) if you don’t do unit testing or UAT? I assume you would say no, so they should be part of the sprint. If you can’t do UAT as part of the sprint due to logistic reasons, then do it as soon after as it makes sense.

• If a sprint consists of stories that are not part of the same stream of work, how would you get a sprint goal?

o You may end with a compound goal. If work is from all over the place, then you may not really have a coherent goal at all. That can happen, I just hope not too often!

• Can you please speak more about the Sprint Goal? I struggle with this because I always want to say the sprint goal is to complete the committed work. What should the sprint goal be and how does the team use/consider it during the sprint?

o Completing the committed work is the implied goal and need not be stated. In Essential Scrum, I define the sprint goal like this: “Each sprint can be summarized by a sprint goal that describes the business purpose and value of the sprint. Typically, the sprint goal has a clear, single focus….” (then I go on to give a bunch of examples).

• Is there a recommended tool to use to capture what was discussed during a sprint review or retrospective?

o Nope, whatever works for your team! Or no tool at all if your team decides capturing what was discussed is not valuable.

• Do you agree with the concept of "Sprint Zero"? What about "Design Sprints"? These seem to be "Waterfall in disguise"... Both usually longer than the agreed sprint duration.

o I dislike specialized sprints. Each sprint ought to be where we develop potentially shippable software or otherwise deliver value agreed to by the product owner. Look, there is definitely work that needs to be done before Sprint 1. What, did you think that trolls met us at the Sprint 1 planning meeting and magically delivered to us a groomed product backlog that was ready to use? Of course not. There is some work that happens before Sprint 1. I just don’t call that work before Sprint 1 a sprint. I call it portfolio planning, product planning, release planning. See Essential Scrum (or come to a CSPO class to better understand). And if we are going to have a design sprint, then heck, let’s go all in. Let’s have an analysis sprint, followed by a design sprint, followed by a coding sprint, followed by a testing sprint. Say “hi” to WaterScrum!

• How should one estimate the number of sprints required for a project? o If you are working on a fixed-­scope project, then you would need a rough idea of the magnitude of the work (say in story points). You could then take your team’s velocity range (high and low velocities) and divide the high and low velocities into the size to

determine a range of how many sprints would be needed. If you are on fixed-­date project and you are doing fixed-­length sprints like you should be doing, then you would do simple calendar math to answer that question. Obviously, there are other approaches, but those are some simple ones.

• Can sprint retrospective also be used to discuss the project/work related challenges the team encountered? Or is this meeting strictly to discuss how we are doing on Scrum practices?

o Anything related to HOW we are doing our work is fair game for the retrospective.

• Can sprint planning be done during the prior sprint? o Yes, but it typically isn’t. The few times I have seen this is when members of the same team are distributed by many time zones (e.g., India and California). In such cases it might be necessary to plan Sprint 2 before we hold the review and retrospective in Sprint 1. Otherwise, team members in one geography can get blocked for a day waiting for Sprint 2 planning. Draw the picture yourself and you will see the issue.

• For a sprint where you have knowledge acquisition and technical tasks, what will the sprint review look like?

o A review on knowledge acquisition might be: “In this sprint our goal was to evaluate architecture alternatives 1 and 2. What we did was run the following tests. Here are the results. And here is our recommendation.” For technical work in the product backlog, you would have already agreed with the product owner on the acceptance criteria that you would use.

• Are sprint planning and review mandatory? What value do they have if the team doesn't have anything to demo?

o If you have nothing to demo, then you certainly need a retrospective to discuss why. If you truly have nothing to demo (which implies you got precisely nothing done during the sprint – could happen, but not likely), then you might not hold the sprint review. However, in many organizations they would still do the sprint review so that the stakeholders could better understand where things are in the project and offer input on what might need to happen next given the failure to deliver anything this sprint.

• Do you recommend testing within the sprint? Both unit testing and SIT? o Yes, all of the work necessary to get to a done state should occur during the sprint!

• For sprint planning, how much time do you recommend spending on the current sprint, the next sprint, and the next release?

o Sprint planning happens at the start of every sprint and the general rule is to time-­box it to be no more than one hour per week of sprint duration.

• Have you ever seen a company succeed by condensing all teams’ sprint reviews into one larger review?

o Yes, in fact in a multi-­team environment where the teams’ work has to be integrated, I would argue this is the preferred approach! Show the stakeholders one integrated whole instead of separate reviews for individual team pieces.

• How do you incorporate knowledge acquisitions user stories in the sprint cycle?

o Create a PBI for them, size them, and put them in the product backlog in the correct priority order. When its time, move them into a sprint like any other PBI.

Stories

• Do you assign stories/tasks to individual developers? If so, do you write the tasks based upon the skill of the chosen developer?

o Stories are not assigned to individual developers. You should have at least two people work on each story, unless you plan to violate the anti-­pattern that I can’t do the final testing of my own code. A task, on the other hand, might be done by an individual. Typically, the person best able to do the task will do it. But that is a decision that a self-­organizing team gets to make!

• Ken, you are showing going from a feature directly to tasks... where are the user stories in your model? Aren't features comprised of stories?

o I was using the term feature in a very loose way to mean anything of value to the customer. In most organizations, they represent scope at various levels of details (e.g., epics, features, stories).

• Who should write the AC for the US? o Product owner owns the acceptance criteria for a user story. But since grooming is a full Scrum team activity, everyone can have input.

Team

• Is scrum appropriate for teams smaller than five people? What other non-­scum options are there for tiny teams, less than 4?

o Sure, I have used Scrum with a three-­person development team. If you really have a tiny team, then you could custom design your own process based on core Agile principles.

• Taking into account holidays, mandatory company meetings, etc., how would you allocate capacity for a team member in percent terms?

o I ask each person for a range of hours she will be available on a typical day during the sprint. I let each individual answer for herself, and we use that data to determine capacity (I give a detailed example of this Chapter 19 of Essential Scrum). If you really just want to use a percent for all team members, published data typically shows people spend about 70% of their time doing value-­adding project work.

• With the development team roles, in my experience the developer roles (i.e. C#, DB, Front-­end Dev, QA, etc.) have individuals who can't or don't want to do the other role(s). In Scrum, development-­team individuals are supposed to be able to do anything to get the story done within the sprint. How have you seen this handled well at different companies? As you mention, how do you avoid falling to a mini-­waterfall within a sprint cycle?

o I favor teams comprised of people with T-­shaped skills and those who have a musketeer attitude. See this blog for more info: http://www.innolution.com/blog/t-­shaped-­skills-­negative-­covariance

• In a scaled Scrum team environment should all teams have the same ScrumMaster for co-­ordination? If not, how can teams co-­ordinate?

o This comes down to how many teams can one person be the ScrumMaster for. If you have a small number of teams and one ScrumMaster makes sense, then you can do it that way. But at any reasonable scale one person cannot be the ScrumMaster for all of the teams. You might very easily scale the ScrumMaster role hierarchically (have an Uber ScrumMaster – there are many variations on this). Also, a lot of the scaling approaches that are commonly available have their own specific solution to this problem. BTW, the default multi-­team coordination mechanism in Scrum is called Scrum of Scrums.

• Do you think Scrum works well for remote teams? o It works for remote teams (well enough). It works better for co-­located teams!

• What do I do if team members parallelize too much and have too much work in progress?

o Remind them that in Scrum it is never about what you start;; it is only about what you finish. The rule: Swarm to the fewest reasonable number of items to work on a one time.

• When dealing with multiple Scrum teams with different SMs and POs, who maintains coordination between each Scrum team?

o The individual teams should do this. Coordination isn’t something individual teams should delegate! Of course at large scale, there could be specific roles involved.

• In a cross-­functional team such as with an ERP environment, do you recommend voting on effort estimates for tasks by the sprint team?

o All members of the development team should be involved in the estimating of product backlog size estimates. Individual tasks might be estimated by one or more people depending on who can do the work.

Velocity • What if a team fails to complete the items in their backlog within the agreed-­upon time-­box? Do you move the incomplete items into a new sprint?

o Not necessarily! You move the item back into the product backlog in the correct priority order. That might be the top of the backlog so you work on it in the next sprint;; it might not be at the top if there are other items that are higher priority.

• Would the velocity be affected if the team has sprints of different lengths (2-­4 weeks) with the same number of hours the team members can commit to each due to holidays, vacations, training, etc.?

o Well, technically velocity is the rate at which the team completes work for the product owner. So the actual rate would not be affected. However, it is fair to assume that a team will complete more work in a four-­week sprint than it will in a two-­week sprint. So, the issue will be that sprints are no longer a normalized unit for reporting. In other words, saying a team gets 40 points of work done per sprint isn’t really a helpful statement if the length of the sprints varies. You would have to normalize to a different unit (like days or weeks), which you definitely can do.

• How can burn-­down charts be created accurately on a daily basis when items haven't been completed?

o Depends on what you are burning down! If you are burning down tasks, I would like to think your team is completing at least some tasks each day (otherwise your tasks are likely too large). In this

case you should be able to produce an accurate sprint burn-­down chart in hours. If the items you were referring to are PBIs (e.g., stories) then if you don’t complete any stories that day, the burn-­down chart would be flat for that day (which is accurate, since no stories were completed that day).

• How do you plan a sprint using velocity? o If you do velocity-­driven sprint planning, you would simply look at your recent velocity and select work out of the product backlog whose aggregate size roughly equates to that velocity. If you don’t give some consideration to the technical aspects of that work, you could very easily make a bad decision and commit to work you actually can’t get done. Many teams I encounter don’t do velocity-­driven sprint planning;; instead they do commitment-­driven sprint planning. See Chapter 19 in Essential Scrum for a detailed comparison.

• Can Ken differentiate between velocity and team capacity? He mentioned how capacity can change from sprint to sprint, but I thought at some point velocity stabilizes somewhat.

o Velocity is the rate at which the team completes work for the product owner. Capacity is the quantity of resources available to perform useful work. Capacity could vary from sprint to sprint for a lot of reasons (e.g., a development team member is on holiday that sprint). Velocity can also vary from sprint to sprint. Of course, if there is less capacity this sprint, the teams velocity will likely be lower.

• How do you start with a new team without any velocity? o You will need to estimate/forecast it. You could ask the team to plan a sprint. If the commitment they are prepared to make looks reasonable, add up the points on the committed stories and use that as a forecasted velocity until you have actual velocity data points.

• What is best way to move the concept of estimates from time based (hours of completion) to the vague measurement that makes up velocity?

o I usually walk through the nuances of ideal-­hour estimating versus abstract relative-­size estimating and let the team members debate the pros and cons. As a broad generalization, about 70% of the teams I encounter use story points. The other 30% use ideal time.