How do you track project setup in an Scrum environment?

Question

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

Answer 1

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".

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.