The Scrum Guide mentions that the developers are responsible for sizing work. Most teams and Scrum Masters interpret that to mean estimating work by assigning it a size. But the Scrum Guide is referring to making work the right size so that it can be completed in a sprint. The goal of every Scrum team is to deliver during a sprint so that the sprint review serves as a cadence for inspecting done work and adapting the product backlog based on the findings and feedback generated. When work is too large to be completed during a sprint, then the sprint review becomes a pointless exercise of reviewing designs and exacerbating scope creep.
Most Scrum teams struggle with sizing work. Rather than dividing large items into smaller items that might fit into a sprint for them, they will assign the larger items a larger estimate and leave them as they are, then plan to work multiple sprints to deliver them.
I will describe here what it means to get work to done, why that work needs to be something that people can use, and then how to analyze the product backlog items for ways in which to divide them to so that they remain usable even though they are made smaller.
Done by the Definition of Done
Every Scrum team is supposed to have a Definition of Done (DoD) that they use as a checklist that every item they work on must meet in order to ensure high quality. Teams doing Scrum are not permitted to consider an item done unless it meets the DoD. If an operations guide must be completed before an item is considered done, then any item without one is still in-progress and unfinished, therefore the Scrum team does not consider it as a candidate for demo in the sprint review.
The DoD serves its main purpose at product backlog item completion. With a DoD in place, there can be little debate about whether or not an item is done. But it also serves another purpose during product backlog refinement and sprint planning: the DoD can be held up to any item we are selecting for work during the sprint to give us an intuitive sense of whether or not all of that work can be completed to that quality standard within the time limit of the Sprint.
Scrum forces a team to make work small enough to fit into the sprint.
Usable and Therefore Valuable
Any product backlog item that meets the DoD is considered done work1. When work is done in Scrum, it should be usable and therefore valuable. Scrum has a rule in it that says the work done by the team each sprint must be usable. That leaves a lot of room for annoying arguments about what “usable” means.” Here’s what I think it means: The customer can use what was produced and demo it back to the team. Examples:
- A new feature in a mobile app. During the sprint review, hand out mobile devices or give them a way to access the app, and have customers use the new feature and see what feedback they give. This is a pretty common software development activity.
- API interfaces. Creating a set of API’s that can be shown and used by other application developers to help them do their jobs better is something usable. This counts as usable because the customers are other developers rather than retail store or online customers.
Here are some examples of work that is not usable:
- A business requirement document. Documents cannot be used by customers. What will a customer do with it? The same is true for all plans: testing plans, designs, sketches, wireframes, etc. Don’t build a plan. The customer cannot use a plan. Build a prototype.
- A database table. Building a table in a database without any application layers with which to see it in action is not usable. You’ve created a layer of something usable, but not a thing that can be used.
- Back end code. Writing code for the front end of an application to use without the front end part is not usable.
- Partially finished work. Any work still waiting on a dependency before it can be used is not usable. Any work that is 99.9999% complete but the developer is still at his desk typing and it could be done any minute is not usable. 2
DRIPS: How to Make Work Smaller and Yet Usable
Our goal is to make a slice of hamburger, not just a bun, not just the lettuce, not just the cheese. We want a pie slice of the whole thing with all of its layers. I guess you could argue that you could use a bun from a hamburger, but you cannot use it as a hamburger. And that is sort of the point. Do you want feedback on progress made, or do you want feedback on how things work? I would think the latter is far, far more valuable. Customers don’t care about budgets, scope, and schedules. They care about value.
The done work at the end of the sprint does not have to be release-ready. It only needs to be usable.
A technique to use to make work smaller is DRIPS3: Data, Rules, Interface elements, Paths, and Spikes. Look at your product backlog item and see if you can see ways to break it down using these concepts.
Data. Do you really have to build the feature with all of the data displayed or communicated, or can you build it with only some of the data in one product backlog item and more data in following items? Breaking work up by data is often fairly obvious.
Example: You are building the account management screen in an application. For the coming sprint review, the screen will be usable if there are four or five data elements present, even if far more need to be added later on for the feature to be considered ready for release.
Rules. Just like data elements not need to all be present for work to be usable and yet small, not all of the rules need to be built into the done work at the end of the sprint.
Example: You have been asked to build a feature in an application, but the feature has a bunch of acceptance criteria telling you to make the feature only available in certain locations, to certain tiers of customers, and in certain situations. Build the prototype with none or just a few rules so it will function and get feedback. Add more rules as you go.
Interface. Divide product backlog items by interface elements.
Example: You are building the feature which will display and allow choices using over 20 interface elements. Look at the interface elements you need to build, and build all database, backend, and front end components necessary to make only one interface element work. Then add more via more product backlog items. Work your way sideways building vertical functionality.
Pathways. Follow the workflow of the feature you are building and have it be usable up to a point.
Example: You are asked to build a new application. Start with the login. Build the interface that accepts the user ID and password, add authentication, and then add displaying the main screen. Each sprint, the customer will be able to proceed further through the workflow path.
Mix and Match. You can divide product backlog items by data, rules, interface, and pathway without using just one method.
Example: Greenfield building of a new application – build the login interface for the user ID without the password and allow anyone to log in. Next, add the rule that only a certain user ID can enter. Then add actual authentication, but do it using the Wizard of Oz technique where the app appears to use authentication but rather lets everyone pass without any complex security attached. Add the security later. Build the function to reset the password as a separate feature later on.
Spike. If you have no idea how to divide the work due to not even knowing what is under the hood of the work you have to do, that’s when you do a spike. A spike is an experimental work item where the developers explore the environment and discover what is possible and how things are put together. It is known to perhaps “fail” in that the purpose of it is not working product but learning.
Small Batches of Work
Create smaller work items to allow work to be finished during the sprint. Many small items completed gives a sense of accomplishment. It impresses customers that things are actually being built and that things are really going to happen in a way that telling them things are 50% complete does not. Gathering feedback frequently and rapidly is important to building the right thing and achieving customer satisfaction.
Don’t allow your Scrum team to become a Zombie Scrum team4 that waterfalls their sprints or regularly works on things by simply labeling them as 5’s and 8’s and allows them to take multiple sprints to build. Get work done during the sprint.
A Scrum team is a team. The purpose of a team is to win. Winning in Scrum is done work at the end of the sprint. Sprints exist to provide a frequent cadence of feedback to the team. The best feedback the team can get is on something that is usable. Success is measured by how much has been completed, not steps through a planning document. Finish during the sprint, get the feedback, and Scrum really starts to happen.
Footnotes
- I didn’t want to use the word increment in this article. I don’t like the word increment, and I don’t like discussions about what the word increment means. I think it confuses people, and knowing what it means and arguing about it doesn’t seem to make people any better at doing Scrum. This is one of those topics where the Scrum edgelords start sounding like nerds arguing about how many magic spells a 4th level magic user can cast in Dungeons and Dragons. So, forgive me Scrum enthusiasts, but I skipped the word on purpose. ↩︎
- The sprint ending while work is still underway is an example of a time when teams are tempted to customize scrum rather than let it make a problem visible so things can be improved. Unfinished work is never reviewed. This forces the team to feel a sense of failure for that work item and to work harder the next sprint on sizing. Sprints are never stretched to finish work in Scrum. Almost completely finished work we are almost done with is never allowed to be demo’d in the review. “But I want to show that I was doing some work!” you say. Then make your work smaller instead of breaking the rules of Scrum to fit your bad habits. The point of Scrum is to get better, not look good. ↩︎
- Lawrence, R. (2015). Patterns for Splitting User Stories. Agile for All. https://agileforall.com/patterns-for-splitting-user-stories/ I did not use Lawrence’s acronym of SPIDR because in my opinion a spike is a last resort, and therefore should come at the end. ↩︎
- Overeem, B., Verwijs, C., & Rothman, J. (2020). The Zombie Scrum Guide: Survival Guide for Professional Scrum Teams. The Liberators. ↩︎