There are 2 broad extremes when doing Scrum. To make scrum-items based on tasks or on functionality.

glossary:

  • scrum-item: item of work on your scrum board/backlog, that you will assign story-points to in a refinement

  • task-item: scrum-item that has a clear amount of work

  • functionality-item: scrum-item that has a clear amount of functionality

I’ll be using these names to be able to clearly differentiate between task-items and functionality-items. I’m avoiding the word "story" here because people tend to call their scrum-items stories, regardless of if it’s a task-item or functionality-item.

Bugs will usually be a separate scrum-item in either way.

Functionality-based Scrum

Your scrum-items are functionality-items.

These may be divided into lower-level "tasks".

You can give them acceptance criteria.

This is theoretical scrum, as it is meant to be.

To be able to do this however, it’s important to not give story-points too much significance.

advantages

  • Your scrum-items are clear to the business

  • less scrum-items

  • when the item is done, the functionality is completely done

disadvantages

  • work/time needed can vary a lot

  • scrum-items can take multiple sprints

Task-based Scrum

Your scrum-items are task-items.

These may be grouped into higher-level "epics/sagas" to see what functionality they belong to.

Because managers and scrum-masters like predictable measurements, Scrum will often gravitate toward using task-items.

Because new task-items will be added while working on some functionality, functionality is even harder to plan than when using Functionality-based Scrum.

advantages

  • easy to plan scrum-items

  • more consistent velocity

disadvantages

  • more scrum-items

  • more administration

  • harder to plan functionality

  • hard to tell when a piece of functionality is done

  • boundaries between scrum-items are less clear

Conclusion

The way many teams do Scrum will fall somewhere in between these 2 extremes.

If a functionality-item turns out to be a lot more difficult it often makes much sense to split off some part of it. Either some functionality or work that can be done later. The important thing is to talk about it with your team.

Sometimes it makes more sense to have a research scrum-item, then refine and do the actual work. Sometimes it makes more sense to do something immediately once you’ve figured out how to do it.

It is important to know what you’re doing. Make sure your team is aligned so you have the same expectations. It can be a source of confusion and frustration if one part of the team does it one way while others do it the other way.

Recognize that you cannot have all the advantages of both ways. You cannot eat from two shores!

Use retrospectives to gently steer your team towards functionality-based Scrum.

And naturally take Scrum with a grain of salt.

shadow-left