4

I understand that in general you create stories with story point complexity, and then define tasks and subtasks in which to mark time against, but how does this translate into items that are outside of any code development?

For example, you are part of an agile team and have a sprint in which you are expected to build and deploy code but at the same time you need to setup a new employee's PC that is starting next week.

How do you include this time? Is this part of the sprint or not? It seems like you need a way to track this time. Even though in my case I fully expect to finish the code for the sprint how would you handle this if it caused you to not finish the items for the sprint? From a management perspective it impacts burndown velocity, as well as at the end of the week if your hours show 3 hours not logged then management could assume you slacked off.

Another example could be something that pulls you off the sprint temporarily like troubleshooting a site outage, server crashes, etc.

How to factor in story points/tasks for non sprint related items, and how do you include tasks that weren't part of the original estimate, like building the PC?

  • These are all great answers, but none of them addresses the underlying question: how to satisfy sponsors who don't understand the uncertainty and complexity of technology development. Those people help keep the teams honest (and they pay us). That's the good news. But the bad news is that in the the absence of value-production at the rate they expected, they demand to know what the teams have been doing (if anything... see the trust problem here?). So teams bulk up on points by pointing anything that they do all sprint. Counting only value in velocity may work well when there is a match betwee – Bob Jun 30 '17 at 21:16
  • @Bob It looks like you have a question that is related (but perhaps not identical) to this one. If so, please feel free to ask a new question, and be sure to link back to this one for context if needed. – Todd A. Jacobs Jun 30 '17 at 22:59
  • @Bob Your comment got cutoff. – Shawn Jul 3 '17 at 14:10
6

TL;DR

Within Scrum, or any sane project management process, there should never be "invisible work." All work that impacts the project's budget, scope, or schedule should be visible to both the team and the organization.

In essence, you are getting hung up on the idea that backlog items or user stories should add value to the product (in your case, a software product), and that anything that isn't part of the software product is therefore an externality. This isn't so; externalities, infrastructure, technical dependencies, and internal process all impact project deliverables and resources, and should therefore be classified as either trackable deliverables or trackable impediments.

Your only viable solution is to make the work visible, and then either charge the cost of that work to the project or accept it as an external dependency. In other words: document it, track it, and adjust for it.

How to Classify "Setting Up a New PC"

For example, you are part of an agile team and have a sprint in which you are expected to build and deploy code, but at the same time you need to setup a new employees pc that is starting next week?

Setting up a new PC is something that is either:

  1. Outside the team's scope (e.g. it's handled by the facilities department, or some other external resource) in which case it is an obstacle to progress that must be accounted for rather than a deliverable.
  2. It is a deliverable for the team. Your cross-functional team does have someone capable of installing a new developer's workstation, right?

From a framework perspective, it doesn't really matter how you classify it. The classification will simply help the team identify those things that need to be done by the team as work chargeable to the project, or help the organization capture external dependencies that will create drag on the project and that will impact the number of stories the team should accept into the current sprint.


Important Note: If you're expecting a brand-new developer on a team to do anything other than create some initial drag on that team's velocity, with or without the benefit of a new workstation, then you are probably Doing Scrum Wrong™. Velocity measures capacity, not management targets, and capacity generally drops when adding new team members due to the necessary overhead of bringing them up to speed.


External-Dependency Stories

In the first case, the user story is reliant on an externality, but should still be a visible cost to the team. For example:

As a new developer,
I need to requisition a new workstation from IT
so that I can be productive.

There may be tasks for the team, such as filling out requisition forms, or going down to the IT department and checking on the status of the new workstation. However, whether or not there are tasks for the team is largely irrelevant; the story is low-effort for the team, but is largely outside the team's ability to influence directly in terms of speed of delivery.

However, it is often useful to have these sorts of stories included on the backlog because they are:

  1. A cost to the project, both financially and in terms of time.
  2. A project dependency that must be tracked.
  3. A coordination item that should be addressed in the daily stand-up until it is resolved.
  4. A process step that should be inspected during the Sprint Retrospective, and adapted if the process isn't meeting the team's needs.

Internal Stories

In the second case, the new workstation is actually a deliverable for the team. If such is the case, then the team should estimate the level of effort involved in ordering, configuring, and installing the workstation the same way that all other project deliverables and dependencies are estimated.

This also provides levers to the Product Owner to manage the project's budget. If the story is something the Product Owner wants to prioritize, then this may indicate that there's value in having a new PC overnighted rather than shipped by Snail Express™. The Product Owner, through the Product Backlog, can determine each and every sprint whether project budget and resources should go to:

  • feature delivery, or
  • essential project dependencies.

Product Owners Responsible for Prioritizing Non-Feature Stories, Too

Bringing on a new team member, and all the associated processes that entails, is something that impacts a project's resources. It is therefore up to the Product Owner to manage the allocation of those resources.

If the Product Owner chooses to de-prioritize stories related to purchasing essential equipment or providing training to a new hire, that's a trade-off that can certainly be made as long as it's explicit. Likewise, if the Product Owner decides to emphasize new equipment and training this sprint in order to improve team capacity in future sprints, that's also a legitimate choice to make explicitly through the Product Backlog.

In either case, the Scrum framework provides for these decisions to be made visible and explicit through placing all project-impacting stories on the Product Backlog. That means that procurement and training stories belong on the Product Backlog, too; it's not just a place where software features sit around waiting to be implemented.

If you're following the official Scrum framework, then I strongly recommend that you add these tasks to the Product Backlog and allow the Product Owner to take responsibility for prioritizing them. If you're following one of the many pseudo-Scrum variants, then you may simply need to reduce your team's expected capacity and accept fewer stories into each sprint until the team has finished properly integrating the new team member.

I can't think of a single case in my own experience where bringing on a new hire doesn't represent a cost to the project or to the organization. Why not make that cost visible, rather than sweeping it under the rug?

  • Great explanation! I changed my accepted answer to this one. Let me preface that we are a small startup without a separate facilities department yet so this falls on our small group of devs. The product owner had set this as a priority and yes it will set drag initially that should be visible. The main reason I was so unsure is the pc item came up after we decided upon the sprint parameters (new hire on short notice), and generally would stop the sprint (scope change)? We currently define our project workflow as software, so should it go there or under a different project heading? – Shawn Apr 6 '14 at 22:58
  • 1
    @Shawn You really ought to ask these as separate questions, if they haven't already been answered elsewhere. 1) Any scope change that affects the current Sprint Goal should trigger an Early Termination and a return to Sprint Planning. 2) In the general case a team should work from a single Product Backlog, so if it's a team responsibility then it belongs on the same backlog as all other team stories. – Todd A. Jacobs Apr 7 '14 at 17:00
9

The answer is really simple and really complex:

Simple Answer: In Scrum you don't

Complex Answers:

  1. If you know the extra tasks before the sprint starts and the team decides that it's necessary to do them, then just do them and lower the forecast. Common courtesy suggests that you tell the PO why you included the extra task.

  2. If you know the extra tasks before the sprint because a manager orders you to do it you are not doing scrum, i.e. the team is not empowered. Ask your Scrum Master for help.

  3. If the tasks comes up in the middle of the sprint and the team decides that it's necessary for you to do, quickly estimate whether it changes the sprint's outcome. If no change is likely just do it. If a forecasted story will not be finished inform the PO but still do it. If it drastically changes the sprint consider a sprint stop.

  4. If the task comes up in the middle of the sprint because it is ordered by a manager you are not doing Scrum. Ask your Scrum Master for help.

  5. There are always support tasks. Lower the forecast. Don't give the support task Story Points. That would suggest work towards your goal.

  6. There are always bugs from stories of previous sprints. Lower the forecast and harden your definition of done. Add more and better tests.

  7. As a PO: The team always does other tasks because the team members have other duties, e.g. other teams. Ask the Scrum Master for help to assign team members to one team only.

  8. As a PO: The team always does other tasks outside the stories. Inform them that you are the Product Owner and that you can choose to work with another team if they consistently ignore the stories.

Meta Answer:

Who cares about the original estimate? It's the features that counts. Think about it: Do you want a product with 1000 Story Points or a product that makes the customer happy? "Story Points" is just a planning tool. There is no customer value in them. So do what is necessary to build a great product. If anyone counts Story Points, ask your Scrum Master for help to overcome the trust issues.

  • @enmos proje thank you for the spelling correction. But tasks are not committed, stories are. The question here was about extra work that needs to be done. Only if that work is necessary for the project and known before sprint start and formulated in a story than it can be committed. – openCage Apr 6 '14 at 6:54
  • "Who cares about the original estimate? It's the features that counts." FTW! Read the manifesto: "Working software is the primary measure of progress." – Alan Larimer Jul 1 '17 at 16:13
7

I personally wouldn't include non-product related tasks like setting up a new PC in the sprint.

Rather I'd identify the team member needed to do the 3 hours of setup and reduce their amount of availability in the coming sprint. Just like you would if a team member has a vacation or is only available x% of her/his time in the sprint.

Any amount of capacity reduction in a team member during a sprint will of course also reduce development velocity. But your burn-down chart won't be affected by a non-product task, and it's easy to explain the slightly lower velocity ("John had non-sprint tasks to care of").

As for cases like server outages: These are (hopefully) rare events which reduce team capacity unexpectedly and thus both velocity and burndown chart suffers. In such a situation just address the event, its consequences and future prevention strategies in the following sprint review and retrospective.

5

The first answer is exactly what you would expect on a PM site and is wrong, for the very reason it gives as being right: "In essence, you are getting hung up on the idea that backlog items or user stories should add value to the product (in your case, a software product), and that anything that isn't part of the software product is therefore an externality." Backlogs track business value. As it burns down, value should burn up. If there are things that prevent it from burning down, including them in the backlog gives the wrong impression that the backlog is bigger than it is, and that the velocity is going towards burning it down. Instead, lower your capacity and show how "externalities" are impacting your progress. To do otherwise is not transparent. The only reason we try to establish a velocity is to create some "predictablility" in a process we know is not. If you hide work like this, you undermine that.

  • 1
    No, although this is a common misconception. Backlogs track work, and including the work on the Product Backlog is how you ensure that you don't have invisible work. While PBIs should have value for the project, the phrase "business value" is not contained within the Scrum Guide. – Todd A. Jacobs Jun 30 '17 at 22:56
  • The Scrum framework isn't about tracking work. The pillar of Transparency isn't the same as the idea of "no invisible work." The Artifacts section of The Scrum Guide clearly and repeated states a focus on the product. A challenge when working with the framework is that it can be too easily translated into classic, command-and-control, top-down project management. Jon Tobey, your observation of the answers here is true. A community focused on project management and not product value delivery will often provide such inaccuracies as answers. – Alan Larimer Jul 1 '17 at 16:36
  • So in capacity if someone was learning the system, getting a p.c. set up, etc., what would you set in the capacity under "Activity"? I don't see "externalities" in the scrum template of TFS. – MilesMorales Apr 5 '18 at 13:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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