We have recently started splitting a big monolith to individual microservices. Now the point of discussion is that under scrum methodology, building microservices should be a feature or chore?

As per the scrum protocols, anything that doesn't provide direct value to users should not be a feature.

  • If it does not provide value to the users, why do you do it? Maybe you just miss the feature that explains why you do it?
    – nvoigt
    Commented Oct 30, 2017 at 11:53
  • 2
    Everything has a value, and almost anything can have value for users or other stakeholders. It's all in how you choose to frame it. But @AlanLarimer is right: the idea that a PBI must have user-facing value is a misconception.
    – Todd A. Jacobs
    Commented Oct 30, 2017 at 14:38
  • Scrum Framework says nothing about features or chores. A backlog can contain numerous types of work items, not all have to deliver business value to the customer. Implementing a particular microservice could be a task or subtask that fall under a user story. It could be a technical debt or possibly a tax? Its good practice to have varying work types. Finally, what Scrum and other Agile Frameworks do ask is that we deliver at least some business value each sprint. Early in a project, this can be just one story; e.g. As a user, I can sign up using my Twitter account so [reason].
    – Muhammad
    Commented Nov 1, 2017 at 5:24

3 Answers 3


There is only one definition of Scrum: The Scrum Guide. The word "feature" appears only once and "chore" not at all.

The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases.

The idea that "anything that doesn't provide direct value to users should not be a feature" (or Product Backlog Item) is a Scrum mandate is a common misconception. It is a valid question to ask, "Should there be more focus on user value versus technical tasks?"

If the effort is purely a technical one and not providing new value, perhaps Scrum is not the best approach. Perhaps a Kanban model is more appropriate. Exposing services can be an opportunity for new integrations and sales (i.e. value) to existing or new users.

If Scrum is used, then it is up to the Scrum Team to determine how to best organize and manage the effort. It's a framework, put the processes and techniques in place that best support the needs of the team. Just keep it all within the roles, events, artifacts, and the rules or don't call it Scrum.

Scrum’s roles, artifacts, events, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.

  • 1
    +1 breaking down a monolith is likely a multi-sprint effort so using Kanban to track progress makes more sense. Commented Nov 7, 2017 at 12:33

I imagine following scenarios:

  1. Customers / Users / Stakeholders complained about performance / experience
  2. Deliver changes quickly / frequently to customers / market
  3. Technical Debt / Lets do something because there's no work or its boring

In case of #1 and #2 above, you'd have proper elicitation with stakeholders / product owner and initiate a project. Product Owner will specify why and what which becomes a project. A project will have start date, end date and outcome. You'll map out deliverable which becomes epic / story / feature.

In case of #3, customers don't care much. So, product owner or sponsor would be either your tech lead or development manager or CIO or anyone who is heads tech team. Still, in this case as well, you'd first specify Why, What and then how - which becomes feature.

In summary, if something is started without setting start/ end/ agenda / outcome, its a chore - doesn't really get anywhere and is probably a WaterScrumFall. If you've done the proper project management, set goals and outcomes, then whatever you do can be set as features.

I could be wrong but I get an impression you're searching for value in work you've already started. Shouldn't you be first looking for value and then start work? Also I'd ask What was the motivation ? Who is the sponsor / Stakeholder?

  • Initiate a project almost always means not agile. Commented Jan 13, 2018 at 21:56

As a long-time sysadmin, I lobby all agile teams to include the internal "run", "ops", or "devops" team as a customer - somebody has to keep this thing running and you can't just ignore them. If breaking the monolith helps this "ops" team, then you can still count it as a feature, just a feature for customer with a different priority.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.