9

Here I am in the process of scoping and estimating a relatively small new software development project. I have been through the user stories suggested by the customer and placed tasks against each, with an estimate and some brief notes on how the task will be accomplished. There are acceptance criteria. All ought to be good with the world.

enter image description here

When looking at the work I'd planned, I realised there was something missing. There is going to be initial outlay in simply setting up things into which we can bolt functionality. Things that belong to all user stories, not one particular user story.

For example, part of this application is a service that parses XML. From the user's point of view there are specific stories where different things will need to be done depending on the content of the XML. Actually writing an XML parser - the bits that look for a file, read it and pull out the relevant data before deciding what to do with the contents - is part of all those stories. As is wrapping it in a windows service with an installer etc. It is a developer-centric task with no direct relevance to a user.

Another relevant example from this particular application is taking and rewriting a block of poor legacy code which is useful to the functions of this app. Again, this has no immediate outcomes for the user but it's necessary work. Where does the planning and execution of this work "live" in a project plan focused on user stories?

I have seen people solve this by writing user stories "As a developer, I want to ..." but as has been discussed elsewhere this isn't a user story. It's a developer one.

I am seeking a concrete answer to this, to help me (and others) planning projects using strict management frameworks like TFS online. These do not tend to have the function to make "stakeholder stories" or other vague meta-solutions mentioned in the answers to How does a Scrum team account for infrastructure tasks in the planning meeting?

Community
  • 1
Bob Tway
  • 3,606
  • 3
  • 21
  • 26
  • 2
    If I tell you that a computer or a service can also be treated like a "user," does that alter your analysis? – Robert Harvey Jan 19 '17 at 17:25
  • 3
    Possible duplicate of [How does a Scrum team account for infrastructure tasks in the planning meeting?](http://softwareengineering.stackexchange.com/questions/61529/how-does-a-scrum-team-account-for-infrastructure-tasks-in-the-planning-meeting) – mmathis Jan 19 '17 at 17:26
  • 1
    @mmathis I saw that question, and it's similar and relevant. However, none of the answers actually answer this question. Especially when you factor in a focus on how to do it within existing frameworks like TFS. – Bob Tway Jan 19 '17 at 17:27
  • @RobertHarvey partially, yes. That would cover the service in this instance, but not the legacy code. I can think of other situations where that approach might not cover the requirements. I'd also be interested to know how widely accepted that is: seems like a semantic change to get around the "as a developer" problem. – Bob Tway Jan 19 '17 at 17:28
  • Well, the only material difference between an end-user and a system-user is the nature of the UI. It doesn't change the development management process one iota. Your scrum process remains the same whether you're catering to an end-user, a stakeholder or another system. See [here](https://www.mountaingoatsoftware.com/blog/writing-user-stories-for-back-end-systems). – Robert Harvey Jan 19 '17 at 17:47
  • @RobertHarvey I think that's a slippery slope, honestly. If we're allowed to leverage non-human "users," the product owner is somewhat free from the due burden of justifying *all* of the team's work. Taking an integration, for example, even if the *immediate* user is other software, if there's no *final* human user, why do the work at all? ... User stories are about solving a person's problem -- even if it's vague, like, "As the CEO, I want to spend less money on hardware" or something. User stories are about addressing a human-facing concern; not the implementation details. – svidgen Jan 19 '17 at 17:48
  • @svidgen: So do you propose instead to write specifications for the infrastructure and put those into the sprint? Or do you still need some sort of story to make it legitimate scrum? How do you address the specific idiosyncracies of TFS? The work still has to be defined somehow. [See also](http://rgalen.com/agile-training-news/2013/11/10/technical-user-stories-what-when-and-how). – Robert Harvey Jan 19 '17 at 17:50
  • @RobertHarvey Just skimming the article, I think the author misses the point of the story format. The "title" -- the "As a X, I want Y" part -- is primarily for the identification of the problem in a manner that both the business and the developer understand. They're not tasks. Tasks and details live *under* the story and fulfill it. The stories themselves are solvable business problems (or deliverables) that the business can acknowledge, hold developers accountable for, and derive value from. – svidgen Jan 19 '17 at 18:02
  • @svidgen: I hear what you're saying, but I feel like there are dangers to treating the outside edges of a system that users can see as the only important top-level artifacts in a scrum scenario. Sure, stakeholders might not be interested in system-level details, but hiding them merely makes the whole thing a giant black box, and perpetuates the misery of "why is this taking so long?" – Robert Harvey Jan 19 '17 at 18:05
  • @RobertHarvey I'll try to bang an answer out soon to hopefully clarify. But, I think the effect is a net good. You provide stakeholders with visible stuff they can hold you accountable for; and you don't ask them to hold you accountable for things they know nothing about -- that's a loss of accountability. They can't verify that work meets requirements they don't understand. Nor can they speak to the necessity of that work. They can only speak to deliverable they understand. The fact that you *deliver* affirms that the technical details were appropriate. – svidgen Jan 19 '17 at 18:11
  • @svidgen: For system and technical user stories, I assume that the stakeholders are internal people like the Project Manager and Team Leaders, not the customer or the end users. – Robert Harvey Jan 19 '17 at 18:13
  • @RobertHarvey Potentially. In many of those cases though, I'd expect the work to be non-sprint work -- much like the time you spent getting things squared away with HR when they changed insurance carriers *again* ... Though, if you're touching a product *in some way*, I'd argue that we can *at least* identify time-savings for employees, which equals business value. – svidgen Jan 19 '17 at 18:21
  • Eeek. Why in the world would you want to take major development *out of a sprint?* – Robert Harvey Jan 19 '17 at 18:23
  • @RobertHarvey I wouldn't, really. I'm trying to leave room for "work done by developers" that isn't exactly "development" or "improvements to the product." Because not everything a developer does will be valuable. And neither the business nor the developer should think everything the developer does increases the value of the product. – svidgen Jan 19 '17 at 18:23
  • 2
    You can cheat at have system users, and iteration0, or you cut the cake differently. First feature gives some user functionality and the infrastructure that is needed to get it to work. Then feature 2 that consequently brings up some more infrastructure, this way you don't wast time setting up infrastructure that you do not need. If you are now screaming but that means I need to re-plan, then you are not doing agile. – ctrl-alt-delor Jan 19 '17 at 22:33

3 Answers3

12

I like the other answers that say to put as much "tooling" code as you can into Iteration 0. However, sometimes, these kinds of tools come up after the project has already started. Perhaps in Iteration 3 you realize you need a generalized XML parser widget to be used on various stories going forward.

In that case, the first User Story that relies on these internal architectural pieces is the one that they belong to. If you are about to work on Story #345, and it will depend on your XML parser before it can be counted as 'done', then your re-usable parser will be attached as work for that story to be completed.

My team has used the above approach and it seemed to work fine for us.

Graham
  • 3,833
  • 1
  • 21
  • 18
  • I was going to answer similarly to this one. If a story needs something, it's a part of that story. Some stories might just get the benefit of coming after another story that built out the infrastructure. However, you need to keep all those stories that need it requiring it just in case stories get re-prioritized. You can't be sure what the first one will be. – Jay S Jan 20 '17 at 12:51
  • 1
    +1 This touches on a great point. Whether it is called iteration 0, 1 or whatever is a bagatelle. All but the most unreasonable or uninformed understand that some groundwork is required. If you paint, you prep the walls, if you cook, you chop, if you're a musician, you practice. – Robbie Dee Jan 20 '17 at 12:51
6

If it's infrastructure it's typically put into Iteration Zero. What's Iteration Zero? It's typically the time between kickoff and planning before actual iterations start.

An example, say we need a new web service. So, I need to create the project, set up continuous integration, set up a source control repository, set up build script and automated deployment, etc. Users doesn't really care about these, but we need these regardless.

So, that work would be done in iteration 0. By the time iteration 1 started, there would already be a new project shell that would compile, have an automated build script, and would deploy. Now, none of the user functionality would be there, but it's ready to go.

I would still track and plan this work as part of iteration 0 work.

The refactoring sounds like a technical story which can go in any iteration.

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
Jon Raynor
  • 10,905
  • 29
  • 47
  • 4
    +1 because we use this as well, but in reality Interation Zero is the new Iteration One. It's just an iteration that the business stakeholder doesn't really care about, but is necessary to get to the things the stakeholder cares about. – Greg Burghardt Jan 19 '17 at 17:53
  • You can have a bona fide iteration 0 but that isn't to say you can't start delivering value from day 1. You don't need a build server, automated deployment and source code repository to start cutting code - this can happen later (or even in parallel). – Robbie Dee Jan 20 '17 at 12:55
3

Depends on the infrastructure.

If the infrastructure is very significant, or has to adhere to complicated compliance regulations, then you may have a separate infrastructure team, who may have a schedule of their own. It might be Agile, it might be waterfall. In this case, the construction of the infrastructure would be managed in your project as an external dependency.

If the infrastructure is going to be managed by your team, and set up only once, you can use the iteration 0 technique that Jon describes.

If setup of the infrastructure will take several iterations (e.g. maybe you set up your build server now but QA and preprod servers will be built a little later) then their buildout can be managed as nonfunctional PBIs. Functional PBIs may have certain dependencies on these, which you can codify in TFS using the "predecessor" link.

And of course you can mix and match all of the above. For example, you can't do much without a continuous build server, so you could put that in iteration 0. Meanwhile your preprod servers might be defined as tasks for iterations 2 and 3, and they may have external dependencies on your DBA team (who aren't Agile) who will be allocating you DB instances in your data center. Or maybe you have to wait for SSL certs to be issued for certain features; they can go in iteration 4, and any functional items that rely on those certs should be linked to them with a predecessor/successor relationship.

In all cases, remember:

  1. Always define clear acceptance criteria. Hardware guys have an annoying tendency to stand up a server and call it done when it has not been validated at all.
  2. During your team's iteration kickoff, the team will need to examine the dependencies and their availability before committing to any PBI or work item.
Community
  • 1
John Wu
  • 26,032
  • 10
  • 63
  • 84
  • *Hardware guys have an annoying tendency to stand up a server and call it done when it has not been validated at all* Good point - hence the recent prevalence of DevOps. – Robbie Dee Jan 20 '17 at 12:58