We are kicking off a new project following Scrum procedures and we realized that at the beginning of the project we have to prepare a lot of things that are not user related (so they are not user stories):

  • Create project skeleton
  • Create continuous integration system
  • Set up policies and procedures
  • Create and structure the backlog

How do you track these tasks in Scrum? I would prefer not to use User Stories as we plan to use them to track how much value do we add to the product and these tasks are not adding value to the end customer

  • At least in this team, a lot of it seems to be contained in the teams' minds only. Of course that's not a good solution for Bus Factor and other reasons.
    – user253751
    Jul 6, 2018 at 5:59
  • 6
    "these tasks are not adding value to the end customer". That line of reasoning will lead to spiralling decline in quality as and attempt to use improved tools, refactor code etc will always be seen as not adding value to the end customer and therefore should be low priority. Anything that speeds up deployment and leads to a more robust product adds value to the end customer.
    – David Arno
    Jul 6, 2018 at 7:02
  • @DavidArno: to me anything that speeds up deployment helps adding value to the end customer faster but does not add anything. I cannot finish an sprint, generate a new release and demo it to users with only 'features' that allows developers do they work faster. And if the project ends after you have done one of these tasks you're not adding anything at all. Jul 6, 2018 at 12:49

6 Answers 6


If you are asking what the scrum guide has to say about this, it says nothing. The scrum guide doesn't differentiate between the types of work that is managed by scrum. All work are simply product backlog items.

While user stories are a useful manifestation of product backlog items, there's nothing particularly special about them. Scrum is about visibility and adapting to change, and you can (and should) do that for all work, not just user stories.

All of the things you mentioned -- Create project skeleton, Create continuous integration system, etc -- are product backlog items that need to be done by the team to accomplish the sprint and release goals.

If you are concerned about how to bill them, the simplest solution is to add a "billable" flag to all of your billable backlog items. For example, use different colored story cards, or configure your software to add a tag or other identifying mark. Or, simply prefix non-billable items with "NB" in the item title or name if you have no other options.

TL;DR: The three pillars of the scrum process are "transparency, inspection, and adaptation", not "transparency, inspection, and adaptation for billable hours only".


In Scrum, all work done by the team should be tracked on the backlog. This ensures that there is transparency about the work that needs to be done to deliver a product.

The backlog does not only contain user stories, but it can also contain other types of backlog-items, such as technical debt, bugs, improvements and those project-setup tasks you mentioned.

If you want to differentiate between the different kinds of backlog items, you can use different colors of cards if you are using a physical scrum board, or use different ticket types if you use an electronic board.

  • I agree with you, the thing is that normally Scrum apps only have User Stories and Bugs (by default). Would you create a different ticket type to track that? Jul 6, 2018 at 6:25
  • 3
    @IgnacioSolerGarcia, this is one of my bug bears with scrum. It's supposed to be an agile methodology, ie "people before process". If a proscriptive aspect of scrum doesn't suit you (eg needing things other than user stories and bugs in the backlog) then ignore that proscriptive aspect and do what works for you. Agile == flexible, not "slavishly follow the laws of scrum"
    – David Arno
    Jul 6, 2018 at 7:05
  • 1
    @DavidArno: Agile (and Scrum) is also about transparency to your stakeholders. It is not a free-for-all in the "people before process". Also, default settings or limitations of tools should also not define how you implement your agile process. Jul 6, 2018 at 10:00
  • 3
    @IgnacioSolerGarcia, we follow scrum, and we also have "Spikes" and "Tasks" in addition to the user stories and bugs. I've not seen anywhere in scrum processes that says you only have bugs and stories. A spike is a short term research task to better handle another item in the backlog. A task is something that has to be done to support the project, even if it does not directly benefit the end users. It most definitely indirectly benefits them through being able to develop more quickly. Jul 6, 2018 at 11:18
  • 3
    " I've not seen anywhere in scrum processes that says you only have bugs and stories" - not only that, but nowhere in the scrum guide do they mention stories at all. Stories are typically used with scrum, but the only thing defined by scrum is a product backlog item. That item can be literally anything. Jul 6, 2018 at 14:41

Our company follows scrum, and there are some common practices that really help in the inception phase:

  • Sprint 0 is about getting your environment set up enough to work
  • Sprint 1 is where you start adding value
  • Tasks are for infrastructure work
  • Spikes are for research needed to either refine the design or discover a root cause for a set of bugs

Typically, a company has a standard way of putting together applications, unless the company is a start up working on the first project. Sprint 0 is about putting in that dirt road so that you can start adding value. It will have tasks like setting up the development environment, getting your repository initialized with the project skeleton, spikes to help refine the first set of user stories, etc. Essentially, as much as you can get done within a sprint.

The first couple sprints may have reduced velocity while you are prioritizing both application features and improving the infrastructure. You may end up pulling in additional resources for surge capacity to build up the missing pieces (i.e. your integration, demo, and pre-production environments).

Bottom line is that the product owner is involved in the conversation, and all work is tracked in the backlog. All work is prioritized in the same sprint ceremonies (grooming and planning). Sometimes there is a clear dependency of a task needing to be done before a feature. That gets documented and tracked in the backlog so that increasing the priority of the feature also increases the priority of the predecessor task.


You have a couple of options here but they all service the same concept of sprint zero, adequately covered in other answers.

If you must demonstrate value from the off, all stories can be framed from the user perspective. It takes some doing but only the most inert of customers would fail to accept that you'll want say, a build server and some ground work put in from the start. You wouldn't expect a painter say, to rock up and start throwing paint at the walls without some preparation.

If you have some free reign, then you can frame the stories from the perspective of the various stakeholders e.g. As a developer I want a build server so that I have a clean build environment

The nuts and bolts are the same in both cases, it is just a management call generally as to how the work is framed.


This is an excellent question and an answer that states "Here's what the SCRUM religion says so you are wrong to do otherwise" is really of no help. This is doubly true in the classic scenario where the Product Owner is a renamed Project Manager and the SCRUM Master is the engineer seen as most management friendly (or the unwilling lead engineer pushed into the role). In that scenario there is a tendency to push the team as quickly as possible to define something/anything that can be estimated to provide a project length rather than to sensibly examine the problem domain using fixed length Spikes whilst also putting infrastructure in place.

The approach to this part of a software project which makes most sense to me is to have an Inception phase. This is best described in the Disciplined Agile model. This consists of a pre-Sprinting phase (akin to a Sprint zero) where the Architectural Owner and lead engineers meet with the PO and then resolve large and nebulous issues of project definition. The rest of the team can tackle work from previous projects or embark on learning exercises for a short time so that people's time isn't wasted.

I would however classify something like the continuous delivery pipeline differently. You don't necessarily need a full pipeline before starting to work. You could allocate 30% of your first couple of Sprints to putting this in place and in the meanwhile define a documented delivery process e.g. build on a clean box, run code tests and copy to a staging area where "features" can be manually verified.

  • 1
    the OP has the tag "scrum", so an answer that comes from a scrum perspective is totally valid. No reason to disparage other answers, and no where did he say you were wrong to do something different. The whole first paragraph is not constructive. Jul 6, 2018 at 11:13
  • I wasn't disparaging your answer. There is no need to take it personally. I'm just giving my opinion based on practicing agile methodologies in various environments for fifteen years.
    – Colm
    Jul 6, 2018 at 12:13
  • 2
    That whole first paragraph comes across as a rant, and doesn't really address the question that was asked, and reduces the overall quality of the answer IMHO. Jul 6, 2018 at 14:38
  • I must have read that first paragraph about a dozen times and I see can't how anyone could possibly have taken umbrage with this given that it is their own experience.
    – Robbie Dee
    Jul 6, 2018 at 14:48
  • @BryanOakley So as the OP says he is absolutely brand new to Scrum. He wants to create a backlog as well as policies and procedures. The common scenario here is the one I described in my first paragraph. It wasn't a rant . It is, to me, a likely scenario for a team moving to agile in 2018. I know the Scrum edict on this... it is to put absolutely everything into a backlog. In OP's case I feel this approach will pollute their first experience of Scrum. Therefore I suggested a short Inception phase where they do some housekeeping. Why is this so controversial?
    – Colm
    Jul 6, 2018 at 16:08

These tasks are probably not part of the project. You wouldn't add:

  • rent an office
  • buy computers
  • get coffee machine

Even though they are necessary tasks that contribute to getting the project finished they are assumed to be in place already. Not something that will be repeated for every website you make.

Stakeholders will be annoyed if they see these kind of tasks on the backlog. It highlights that they are paying for stuff which they might not have done if they had gone with another supplier who has already setup their CI server

Delay the start of the project until your setup tasks are complete. Manage them with Scrum or any other methodology of your choice.

Your Answer

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

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