3

Disclaimer: I'm a total agile newbee.

As a project manager for a pilot agile project, I am trying to create a rough sketch of my project using agile methodologies, but somehow I am not sure how to do define each Story in the Epic-Story-Task hierarchy, especially given the "user-story" approach:

As a [user], I'd like to be able to [do that], so that I could [get that].

The problem is, there are no users that I can identify in my project. My project is defined as a communication extension of an existing project, in order to integrate it with a third-party system. A (say) 2-month job which I'd like to divide into (say) 4 or 5 sprints.

  • We need to modify the hardware a bit, then test it at customer's site to see if it will suffice.
  • Then get back to implementing some basic protocols, then test it at customer's site.
  • Implement a bit, do a small release and test it.

Seems fit for small agile sprints.

But I am unsure how to write the Story-level tasks. I am pretty sure that either I got this whole "user" part too strictly, or that I can actually identify users for my stories. I could simply write "Test different communication options" as a story, but it surely violates the INVEST mnemonic.

What am I doing wrong?

  • This question feels a bit too abstract. What are the actual things you're working on. We might be able to suggest some real users. "there are no users that I can identify in my project", sounds more like an excuse than a reason. – Dave Hillier Feb 10 '14 at 21:15
  • @Dave: fair point, that's the feeling I had also. Ok, I'll try to add some concrete points. – Lou Feb 10 '14 at 22:30
  • 1
    Are you sure this is a good fit for Scrum? Works best when the product is uncertain and you need daily or weekly or fortnightly feedback. We don't build houses uses Scrum for a reason. Most infrastructure is not a good fit for Scrum. – Venture2099 Aug 17 '18 at 8:12
5

TL;DR

Without knowing the specifics of your Product Backlog, a concrete answer isn't possible. However, some general guidance on crafting effective user stories may help.

The user in user stories need not be an actual end-user. Rather, it is a viewpoint character that provides context for development and validation of a feature. If you can't identify a person or role that would find value in a given feature, then you may want to revise your backlog so that it represents features rather than tasks, or decompose your stories further until a value consumer is discovered.

Viewpoints in User Stories

A user in a user story can be any actor that would derive value from the feature. Some possible users for your scenario might be:

  • End-users of the communication extension.
  • A specific role staffed at the customer site.
  • An administrator or operator of the communication system.
  • A network engineer supporting the infrastructure that your product relies on.

Identifying this user provides context, as implementation details are not part of a user story. The viewpoint helps the developers craft a solution from a feature-consumer's point of view, and often highlights the acceptance testing criteria necessary to ensure the feature is designed and built properly.

In cases where an actual person is defined as the user, then the story can also act as a conversation placeholder for starting a dialog with the person about the implementation of the feature. For example, if Joe the Administrator is the defined user, then the development team can work directly with Joe to clarify details or flush out issues encountered during the sprint.

Identify Value Consumers Through Feature Decomposition

Stories without a viewpoint are often a project smell. It may indicate:

  • A plan-driven (rather than feature-driven) Product Backlog.
  • "Stories" that are specifications rather than user stories in the agile sense.
  • Featuritis that violates the YAGNI principle.
  • Themes or epics that haven't been decomposed well enough to identify who will receive value from the feature.
  • A story, epic, or theme that has been added to the Product Backlog without value-based prioritization by the Product Owner.

There are certainly other reasons why your stories may lack a user-centric viewpoint, but the list above is a useful starting point for introspecting your backlog grooming process.

In many cases, restructuring your Product Backlog to contain features rather than tasks is a great first step. Once you've done that, you should decompose the features until each feature has some quantifiable value and identified the likely consumer of that value. This process not only helps you write better user stories, but will also help the Product owner to properly prioritize stories within the Product Backlog.

  • +1, Great, you clarified it a lot. But, the thing is, the requirement of the project is something like: "Add two-way communication between our measurement system and the Customer's existing system to allow automatic detection of system states in our system". So, I guess I could write it as a single story "As a user, I would like your system to be integrated with my existing system, so that I don't have to input any information into the new system manually". Is my whole project really only a single story? I know that Tasks are the ones that should be fine grained, but isn't this too broad? – Lou Feb 9 '14 at 16:53
  • Or, one way to look at it would be that it seems like the whole project, as I see it, is a single feature, which will take a couple of iterations to implement due to a bunch of uncertainties that will arise during the development. But I nevertheless already know that we'll have to: 1) test different hardware to ensure specified comm. speeds (yes, there's that "specification" thingy), 2) implement basic protocols and test that the system is behaving as expected, and 3) cooperate with the Customer to polish the UX. But how to do this if my backlog has a single story? – Lou Feb 9 '14 at 16:57
  • @LousyCoder A story must fit within a single iteration. If it doesn't, then it's an epic rather than a story and should be decomposed. My guess is that, for your project, each system state, supported protocol, and UX feature should be a separate story so that the features can be built and tested as independently as possible. --If you really have only a single deliverable that can't be decomposed or iterated over, then Scrum might not be the right choice for this project. – Todd A. Jacobs Feb 9 '14 at 18:04
1

A user story is not about a User, it's about an Actor which could be somebody who performs an action like:

As a Visitor I want to be able to do thing so I can get stuff.

Before you write the user story, you need to define your Actors, who are responsible for an action.

In my perspective an Actor can be a visitor, administrator, or even a system task.

User as an Actor is too broad of a term to be used in a user story.

1

I know this is a necro thread but just in case anyone (like me) stumbles across it. The issue here is not how we describe the story, but how we understand and analyze the requirement, in other words the business analysis activity is missing. If we are not skilled in business analysis, then we are going to have problems writing good stories, irrespective of whether they have clear 'users' or not.

For example the case given in one of the responses ""As a Solutions Architect, I want Entity X's CRUD events to be recorded in a Message Queue, so that EventPublisher can publish them asynchronously".

The question to ask is 'Why does the systems architect want that to happen?" and keep asking why until we reach a point of value, not a feature. Publishing asynchronously is a feature, not a point of value (i.e. benefit).

So why is it that the architect wants asynch publishing from a message queue? I'll make a guess, for purposes of resilience, maybe. So the story can be re-written as something like.

"As a Solutions Architect, I want Entity X's CRUD events to be recorded in a Message Queue, providing the ability for EventPublisher to publish them asynchronously so that we can be sure that in the event of a system failure we will have automatic recovery on startup, enabling the business to immediately function correctly with no need to manually reset consistency in business systems"

Or something like that. Note the benefit statement as written provides the meat for additional acceptance criteria to better inform the testing effort.

In reality if we are specifying entirety X out it is probably feasible to tie the whole story back to a business user or customer since entity X is likely to relate to some business function or another, which could be detailed in the story.

0

I have been in a similar situation before.

We were working on a integration project where the features/requirements were not coming from users. In fact, a criterion for success was that the users didn't notice we had extending their application for integration with other apps.

I was asked to plan this as an Agile project, so I did. But now I regret it.

It ended up confusing everybody. People kept trying to talk about requirements from a user's perspective, they kept trying to manually test from a user's perspective, and they constantly questioned the business value of stories like "As a Solutions Architect, I want Entity X's CRUD events to be recorded in a Message Queue, so that EventPublisher can publish them asynchronously".

Agile as we had done it before wasn't a good fit.

Implementing the work iteratively was OK, because we found out that the spec changed frequently (though this might not be your case). But other than that, a Waterfall approach would have been much nicer.

So, in short. Maybe make use of Agile tools, but plan this as a Waterfall project.

  • Your example story should have been written differently to give it a user focus. "So that something can publish asynchronously" isn't a business value. Likely the business value is something that you gain by being asynchronous like better uptime, better monitoring, faster deploys, etc. etc. I'd write the story like "As a system maintainer, I want (CRUD events to be recorded, etc. etc.) so that deploy time can be reduced from 10 to 5." The story as written sounds a lot like: "Do this because I say so." – Alex B Apr 25 '14 at 2:57
  • The problem with that is that the goal wasn't something like "so that deployed time can be reduced." Management from departments A, B, and C, wanted the actions of users of System X, to be recorded so that they could be relayed to System Y and then eventually used by the accountants via reports in Accounting Process Q. And that's one of the simpler cases. The data we were recording was central to about a dozen processes in the business. A dozen or so roles benefited by having access to this new data, though they didn't ask for it. It was part of a Business Process change initiative. – MetaFight Apr 25 '14 at 9:54
  • Sometimes developing software from a single user's perspective just doesn't make sense. – MetaFight Apr 25 '14 at 9:58

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.