Mastering Scrum: Key Insights on Definition of Done, Spikes, and Managing Ad Hoc Work

Published on
4 minute read

Hello everyone, and welcome back to my office hours! Today, I’m excited to dive into some of the questions that have come up over the past week. As always, I host this event every Wednesday at 6 p.m. UK time, where I gather interesting queries and do my best to provide insightful answers. So, let’s get started!

The Importance of Interaction

Before we jump into the questions, I want to remind you that this is an interactive session. You can join me live on platforms like Facebook, YouTube, Twitter, and LinkedIn. However, I’ve found that YouTube offers the best experience with the least delay, so if you have questions, that’s the place to be! If you prefer to ask anonymously, feel free to use the link provided in the chat.

What I’ve Been Up To

This week has been particularly busy for me. I conducted my fourth Professional Scrum Foundations class online, engaging with around 20 participants across different time zones. It’s been a tiring but rewarding experience, and I’m thrilled with the discussions we had, especially around the roles, artefacts, and events in Scrum.

One of the key takeaways from our discussions was the idea that productivity often outweighs the sheer number of features delivered. As Satya Nadella has pointed out, focusing on the productivity of your team can lead to greater long-term success. For instance, the Azure DevOps team has transitioned from delivering 25 features a year to nearly 300, all thanks to prioritising productivity over mere feature count.

Addressing Common Questions

Now, let’s delve into the three main questions I want to address today:

  1. Conflating Definition of Done with Acceptance Criteria
  2. Spikes vs. Refinement
  3. Handling Ad Hoc Work in Sprints

1. Definition of Done vs. Acceptance Criteria

A common misconception I encounter is the conflation of the Definition of Done (DoD) with acceptance criteria. While they are related, they serve different purposes:

  • Definition of Done: This is a measure of quality that outlines what must be true for a product to be considered complete. It includes aspects like documentation, testing, and performance requirements. Essentially, it’s a checklist that ensures quality across all work items, regardless of their specific features.

  • Acceptance Criteria: These are specific conditions that a product backlog item must meet to be accepted by the product owner or stakeholders. They focus on the features and behaviours expected from the product.

To clarify, the DoD is about the minimum quality required for delivery, while acceptance criteria detail what needs to be achieved for a specific item. Both are essential, but they are not interchangeable.

2. Spikes vs. Refinement

Another question that often arises is whether to use spikes or simply incorporate learning into refinement. Here’s my take:

  • Spikes: These are time-boxed periods dedicated to research or exploration. While they can be useful, I believe they can create a false sense of productivity. Spikes often lead to story points being assigned to work that doesn’t directly deliver value to the customer.

  • Refinement: This is an ongoing process where the development team reviews upcoming backlog items to gain a better understanding. It’s a more transparent way to handle uncertainty without inflating the backlog with spikes. I recommend using refinement as the primary method for addressing unknowns, as it keeps the focus on delivering customer value.

3. Managing Ad Hoc Work in Sprints

Finally, let’s talk about ad hoc work. Many believe that Scrum cannot accommodate unexpected tasks during a sprint, but that’s not the case. Here’s how I approach it:

  • Capacity Planning: It’s crucial to understand your team’s capacity for the sprint. This includes accounting for planned work, business as usual (BAU) tasks, and any unexpected issues that arise.

  • Transparency: Be open about how much time is reserved for ad hoc work. For instance, if you allocate 10% of your capacity for unexpected tasks, make sure the team is aware of this.

  • Retrospective Discussions: Use retrospectives to discuss how to reduce the impact of ad hoc work on your sprint goals. This could involve identifying areas for automation or improving processes to minimise disruptions.

Conclusion

In summary, understanding the distinctions between the Definition of Done and acceptance criteria, the role of spikes versus refinement, and how to manage ad hoc work are all vital for a successful Scrum implementation. As always, I encourage you to ask questions and engage in discussions, whether here or in future sessions.

Thank you for joining me today! I look forward to seeing you next Wednesday, and don’t hesitate to reach out if you have any questions in the meantime.

hello welcome to my office hours 23rd of June

okay so I do this event every Wednesday at 6 p.m. I collect as many interesting questions as I hear during the week the week in between so from Wednesday to Wednesday and then I try and do my best to answer those questions at this event as well as answering it for folks directly as well when they ask me and I have three questions today that I’m going to go over but I want to let you know that you can ask me anything so you can either we are at live on Facebook YouTube Twitter and LinkedIn well I’m hoping we’re live on LinkedIn LinkedIn it’s been a bit funny I did a session earlier and it’s just a black screen so everything else is working apart from LinkedIn so maybe they’re having a problem or maybe my systems having a problem but we’ll figure it out ah the best place to interact is on YouTube it has the best experience and it’s the least delay for you watching if you have a question please ask in the chat for this video you can ask it on any platform I can see theoretically the chat from all the platforms I can’t respond to LinkedIn but I can obviously verily I just can’t reply we have again at YouTube is the best place if you want to ask a question anonymously you can use the link here it’s just our form of the text box and you can ask anything you want about DevOps scrum Kanban agile organizational change metrics whatever you want and I will do my best to answer it I don’t guarantee I’ll have all the answers but if I do not have an answer to a question I will go off in between now and next Wednesday find out an answer and try and get you something for next week if I don’t have one yet so just a recap for what I’ve been up to on Monday Tuesday I did my fourth third no fourth fourth professional scrum foundations class live online for 20 odd people and I’ve done two in Dublin timezone and two in PST so at California timezone and this was a California so I am tired I am waning now it’s 6 p.m. in the UK and that was just when I was starting the class Monday Tuesday so it’s it’s been very tiring but we had a great time during that class I’m just thinking I might show you the mural that we created as part of that class as long as I can type and talk at the same time I didn’t have to type in my password that was pretty good the part of the mural that I thought might be interesting for you let me put that up there and then I’ll zoom zoom out is we had our discussion where’s my magic button there it is well let me let me disappear myself we had a really interesting discussion for I was probably about an hour and a half to build this part of the mural but a really interesting discussion on the roles artifacts and events around scrum and how they all go together and we talked about the ideas that Satya Nadella has been talking about a lot recently which is the M it’s better to trade off features for productivity productivity of your team’s productivity of your people doing the work is actually more important than actually adding features because in the long run you’re gonna get way more features by focusing on productivity let the engineers figure that out a good example of that is the azure DevOps team who eight years ago were delivering 25 features to production each year and today after a massive transition towards agility there are delivering nearly 300 features to production each year if you’re a product owner that’s worth the massive multi-year investment in productivity and setup and so building this was a lot of fun especially with the group of folk that I had we had three teams two teams of six and one team of seven in our group well I think that’s how it broke down there was 20 people and Russell Miller and myself were facilitating that so it was just a lot of fun and we had only two not scrums scrum master accountable for progress and scrum master assigning work or just assigning work to people in general so we had a lot of fun Russell and I and we got some really interesting ideas out of this team so and as part of not just that training but the other questions that have come up folks that have got in touch with me since last week and I get three things that I kind of want to talk about one is the idea that a lot of folks have that conflicts definition of done with acceptance criteria and so I just want to define both of those things to make it make it more more transparent I want to talk about spikes versus refinement that seems to be a common question that comes up that’s always a good one and then what do we do about ad hoc work in the sprint that was one of the conversations that came up during the training on Monday and Tuesday and there’s maybe the belief that scrum can’t handle ad hoc work however that is not the case so let let’s I’ll maybe leave this up I’ll put myself back on there we go and I might I might use a little bit of space there to draw stuff if I feel like it but I’ll leave that up just now so the first one is Inc definition of done with acceptance criteria I see that a lot not just from new people to agility but also with people that have long experience in agility a definition of done an acceptance criteria are not the same thing they are only loosely related to each other so our definition of done is our measure of quality if you were to get everybody in a in a room who’s responsible for shipping your product to production or authorizing your product to ship to production or signing off on your your your product being shipped to production if you had software engineers you had testers you had analysts and you had operations you had security legal maybe and product management if you had all of those folk in a room and you asked them to make a list of all of the things that have to be true regardless of what we’re working on but regardless of that so nothing to do with the acceptance criteria or what it is we’re going to deliver what’s a list of things that have to be true in order for us to ship to production do we need documentation how much what needs to be in it do we need to do testing what type of testing how much testing is okay for us to be happy to ship to production make a list of all of those things that have to be true that’s effectively your definition of done do we need to support 10,000 simultaneous users if we need to support 10,000 simultaneous users then the performance testing for 10,000 simultaneous users has to have passed and there’s all kinds of things like that that can go in there and we might want to think about code quality we might want to think about refactoring we might want to think about readability unit tests code reviews these are all things that go to the quality of our product so we’re not talking about scope or features just the quality and that’s what the engineering team the the scrum team the development team is accountable for the development team is accountable for quality not quantity of work okay and whereas the acceptance criteria are the if you think of a piece of work a product backlog item which might be of any type you like your product backlog item you’re going to have some conversations with the product owner and with stakeholders and your acceptance criteria are your measures by which the folks that accept that your items have been completed to the the level that they desire and are met so I acceptance criteria might be about features it’s going to be about behaviors you might have a behavior based list of acceptance criteria these are all customer centric business centric ideas both the the story the backlog item and the acceptance criteria is around making sure we understand what we’re going to go bill definition of done is around the minimum level of quality required for the how we go build it I hope that kind of separates those two things a little bit and makes it easier to define those two we need a definition of done having acceptance criteria is not good enough to also be our definition of done at the same time we need that extra piece ah okay so that was the first question about conflating definition of done with acceptance criteria it’s pretty common for for that to be something that happens the second question was around spike versus refinement should we have a spike or should it just be part of refinement I get that question a lot how do we handle our something we don’t understand we have a piece of work that we need to do we don’t understand it yet we’ve identified that we need to do some learning or we need to do some experimentation around that piece of work how do we represent that work there’s one school of thought that we should create a product backlog item that would be cut we would call a spike which is a time boxed amount of learning that goes into our sprint and we it has story points and we get credit for for doing that work and I disagree with spikes I don’t believe spikes are necessary and I believe that spikes reduce transparency for the amount of work we can get done it makes it seem like we can deliver more work than we can because we did a bunch of story points that were just investigation work rather than actual work that we didn’t deliver any value directly to the customer you using a spiked spikes our informational output rather than value output or learnings output rather than value output which I’m not saying that learnings aren’t valuable they are and but they’re not what the customer is paying for the customer is paying for value all the stakeholders are paying for value so in scrum there already is a mechanism for a time for the development team to look at things on your product backlog that are coming up in future sprints and gain more understanding of what those items are we call that refinement it doesn’t have a specific event or time box the scrum guide defines it as maybe you shouldn’t spend more than 10% of your time in refinement but the reality is if you’re and if you really understand the stuff on your product backlog you probably spend less than 10% of your time in refinement but if you find something on your product backlog that’s super-complicated that we really don’t understand that we’re going to have to work together work with a bunch of other folks you know get some technology experts in do some investigation talk to the customer discuss trade offs maybe for some things we spend more than 10% of our time during the sprint in refinement we’d like to keep it to the minimum we need but maybe we need a little bit more than we usually do and that refinement is just work that we have to do for things coming up it could be part of our UX work it could be part of our analysis it could be part of a skiing the customer questions it could be implementation things that we need we have to order servers we have to whatever those things are and that for me is just refinement I don’t want it represented on my backlog because there’s an amount of time that we have in the sprint our capacity for the sprint based on the people that we’ve got and any vacations and things they have and some time is just taken away for other things and that’s okay that’s kind of the reality of working in an organization there’s not just one product there’s many other product I as a software engineer may have other responsibilities than just showing progress on a particular product and I might have some support work I have to do I might have some training that I have to go do I might have some some business as usual stuff I need to do some checks in the morning when I come in this is all time there is not product work and if it’s not product work I prefer not to have it represented on the product backlog because it’s not to do with the product it’s not providing us with value everything on the product backlog should be things that are valuable to our customer defined in a way that they can understand our customer our user our stakeholder whatever you want to call it and I think that idea kind of bleeds in to our ad hoc work how do we deal with ad hoc work in the sprint and so what I the way I normally try and explain this is with a little bit of our a diagram okay so let’s say we have we figured out what our capacity for our sprint is and it’s about it’s about this big okay I’ll move that a little bit to the left there we go it’s about this big this is our capacity for the sprint and that includes all the people whatever whatever we’re going to do that’s just the box that we can fill and we’re going to have some things that we know we’re going to have to do so for example and I might take 10% of my time for refinement okay I’ve got a little bit of work doing refinement and that’s that’s work that’s already allocated I’m gonna make sure that you know I know only have 90 percent left to go do that and then I I find out that um we’ve got some BAU business as usual there’s some checks that have to be run in the morning there’s some data that has to be analyzed and has to be done every day or every second day or every week or whatever that is and we look at that work across our whole team and it takes about 20% of our time we just take a look at that and that’s that’s what we feel it takes so this is 20% for what b8 for BAU I’m just gonna call that BAU business as usual so I’m gonna stick that in there okay okay well we’ve get 70% of our time left but we need to hold some of our capacity we you know we’re not our quality level is not where we would like it to be and we need to spend some amount of time working on things that are wrong in production so either productions down there’s a bug there’s a customer support request whatever those things are they’re just things that are not working properly oh my creator posted let’s take that away so we’re gonna spend 20% of our time on support slash live issues you can call that whatever you want but that’s effectively effectively what it is support slash live issues okay so we have 50% of our space left 50% has taken by by other things that’s that’s that’s okay so let’s say we have all of the rest of that time is for our oh no no no we’ve got we’ve got another thing we need to look at let’s say 10% or at bunks you know those little things that happen during the sprint or things that get left over that we didn’t really spot that are too small to fit in a hole sprint goal and but not big enough sorry not big enough to justify our whole sprint goal and but too small even if you you know you don’t want to have a sprint that’s a bug-fix sprint that’s gonna be a major problem so we’re gonna have that ten percent so now we have forty percent of our time which is our work let’s call it our goal our sprint goal and we have forty percent of our time to allocate to our sprint goal is this okay does the scrum guide say this is okay it it does the scrum guide doesn’t say how much of your time during the sprint has to be towards the Sprint goal it just implies that as much as possible this might be what’s possible we might only be able to spend 30% of our sprint focused on our sprint goal so that’s the focus for the team if you think of the scrum values we want focus and we’ve we’ve got some focus but then we’ve got some leftover bugs I’ve got those little little things that we need to fix we’ll get some support incidents because some businesses usually got some refinement okay however everything I’m trying to think how I’m going to represent this I’m just gonna do align all of this piece here bugs ah let’s see bugs and live life site incidents and be a you are and opportunities for automation that’s the way I like to describe it okay all except I can’t spell opportunities but you get the idea and we have and okay I’m gonna get another word for that let’s see if it would let me do that technical debt anything that’s not automated is technical debt so if it can be automated and it’s not automated then its technical debt so maybe our quality level isn’t good enough that’s why we’re getting 10% of our time spent on bugs what can we do let’s have a discussion during our retrospective how can we make that 10 percent smaller how can we change our application change our deployment change the way we do things in order to have less bugs in production that’s that’s one thing we can do why do we have support LifeSite issues is there something we’ve not automated in an admin system that means we have to go do it is there some downtime a good example as the azure devops team ran into an issue where for example if the profile service for Azure DevOps failed then the entire system stopped working does it make sense for you as a software engineer not to be able to commit code because it can’t go pull your profile picture and your friendly display name it doesn’t make any sense it should be able to continue without those things so they had to go and add some work to their backlog they had to do work to change their architecture to support the circuit breaker pattern and that circuit breaker patent allowed them to remove that support time remove that support work and actually allowed them to get rid of some of their bug time as well maybe some of their BAU too because it’s all wrapped up in that things are going wrong in production and we have to go sort Atty we’ve got to go monitor these things because we’re having this problem so there’s some time that we can save there the idea is how can we make the goal bigger and these other things smaller okay that would be one of the things that I want the team to bring up at the retrospective so to answer the question how do we deal with ad-hoc work um it just takes time away from the goal we reserve some time for our ad hoc work we’re open and transparent about how much time we’re reserving I might I might like to see something like this diagram for my team and I want to be able to focus on bring it up the retrospective and focus on what can we do to reduce those things so that was really the three questions that I had today there was conflating definition of done an acceptance criteria they are not the same thing they are separate things definition of done is about the minimum level of quality for delivering how acceptance criteria is about adding more detail to the what I talked a little bit about spikes versus refinement you can have a spike on your product backlog but I think the the a better way is really to focus on refinement as the activity for figuring some of that stuff out so you get out of Ament and and then as part of that story because refinement just takes ten percent of your time up to ten percent of your time or not not on average more than ten percent of your time and I also talked a little bit of a ad hoc work and how that fit into our goal for scrum there sees other things that we have to work on and how do we balance that as a team as long as we’re open and transparent that’s what counts okay so I’m going to leave it there like I said I was up very late I was teaching till 1:00 a.m. last night in PST time zone from GMT so I am tired and I’ve answered all of the questions that we have I would definitely ask if you’ve got any questions that you don’t want anybody to know that you’re asking uh you could use this link here to ask that question anonymously if you are if you don’t mind you can just ask in any of the chats and I will hopefully get to it and please let me know if the LinkedIn video worked I don’t know why there’s a problem there but for now I will see you next Wednesday unless I see you before okay thank you

Professional Scrum People and Process Events and Presentations Software Development Software Developers

Connect with Martin Hinshelwood

If you've made it this far, it's worth connecting with our principal consultant and coach, Martin Hinshelwood, for a 30-minute 'ask me anything' call.

Our Happy Clients​

We partner with businesses across diverse industries, including finance, insurance, healthcare, pharmaceuticals, technology, engineering, transportation, hospitality, entertainment, legal, government, and military sectors.​

Slicedbread Logo
DFDS Logo
Flowmaster (a Mentor Graphics Company) Logo
Qualco Logo
Epic Games Logo
Xceptor - Process and Data Automation Logo
Graham & Brown Logo
Lean SA Logo
Capita Secure Information Solutions Ltd Logo
Akaditi Logo
Lockheed Martin Logo
Genus Breeding Ltd Logo
Philips Logo
YearUp.org Logo
Schlumberger Logo
Big Data for Humans Logo
Boeing Logo
Jack Links Logo
Ghana Police Service Logo
New Hampshire Supreme Court Logo
Royal Air Force Logo
Washington Department of Enterprise Services Logo
Department of Work and Pensions (UK) Logo
Washington Department of Transport Logo
Milliman Logo
Deliotte Logo
Lockheed Martin Logo
Brandes Investment Partners L.P. Logo

CR2

Boeing Logo