5

I'm specifically thinking about the relationship between action items and various methods of organizing tasks in agile methodologies, such as user stories. I think this requires a little bit of a leap, but I don't think it's too off-base.

My understanding of an action item is that it is something that needs to be done. It could be a task to write a document, review a document, implement functionality, write a test case, prepare a presentation, send an email, sign a document, and so on. An action item is also something that can be handled by (and is assigned to) a single individual.

As I understand it, a user story is a requirement in the form of "As a {role}, I want {output} so that {benefit}". Quite simply, it's a representation task. Usually, user stories are used to capture the functional requirements of a system, and then someone will use this requirement to implement a solution. However, I see nothing in this definition that precludes it from capturing non-functional requirements ("As a user, I want this program to respond to {input X} within 1 second so that I can complete this task within the deadlines.") I also don't see a reason why stories can't be written for internal tasks as well ("As a project manager, I want a regular status report on the health of this project to determine scheduling, budgeting, and risks." -> realized through things like daily standups or weekly status meetings).

I came across the INVEST mnemonic when searching about this relationship between action items and user stories. It means that user stories must be independent (self-contained), negotiable (changed up to the time they are added to an iteration), valuable, can be estimated, appropriately sized (4-40 or 8-80 rule?), and testable. I disagree that all stories must be independent (some features or tasks do depend on others existing first) and testable (you can't necessarily "test" a presentation in the development sense, but it can be reviewed and assessed, so it might be close). It seems like with the exception of independent and testable, the same rules should apply to an action item.

Ultimately, the question is: Are "user stories" and "action items" (and any other methods of task identification and tracking) generally interchangable? It seems like a good task is a good task, regardless of how it's presented, and the only significant difference between the two is how they are formatted and presented. Is the only consideration which presentation of tasks bests suits the project and team, and maintaining consistency (in the format used to express tasks) throughout the project?

Improve this question

4 Answers 4

Reset to default
3

Definitely not interchangeable. A user story can be looked at as a high level requirement of sorts. The user story can be used to estimate a relative level of complexity...however, real work has to be done on this story...e.g, tasks.

For instance you could break a single user story into multiple tasks, which would give you the level of granularity you'd need to assign time estimates to.

Hope this helps! If not, I can go into a lot more detail =) Check out slide 30: http://www.mountaingoatsoftware.com/system/presentation/file/85/Cohn_EstimatingAndPlanning.pdf?1267636342

I will say one thing, I guess if you break up the user story to the smallest actionable piece, you would then be using story and task interchangeable. I just tend to think of a story as a group of tasks (e.g, ill create the tasks once it gets prioritized and ready to enter the sprint backlog)

Improve this answer
2
  • That's a good point about user stories typically containing several tasks. A user story to implement functionality in software would be broken down into tasks to write various test cases, implement any business logic and models, database implementation, user interface design, updating documentation, and so on. Perhaps I should be looking at the effectiveness and understandability (and unambiguity?) of various representations of tasks instead (representing all tasks as stories, representing all tasks as "things to do", or some combination of both) instead. Thanks.
    – Thomas Owens ♦
    Sep 9, 2011 at 11:18
  • I'm a really big fan of Mike Cohn's work. Check out his Website and possibly his books for a wealth of information: www.mountaingoatsoftware.com
    – Aaron Corcoran
    Sep 9, 2011 at 13:56
2

,I find most non functional requirements are best represented by acceptance criteria (in the case of something that is a 1 hit does or doesn't happen). As Jesse points out, your example is a good fit for this. More long term NFRs (e.g. "page weight must be below x" or "app complies with security standards") should be considered part of your definition of done which should be checked whenever a story is completed.

As for sub tasks for stories; in my experience, most tasks can be re-written, or the story they come from can be broken down differently to express them as perfectly good stories. Can be tricky on back end stuff though.

Improve this answer
2
  • As I commented on Jesse's post (and might even expand here), might it be advisable, for the sake of management, understanding, and mental modeling, to use the same format for all requirements and tasks? If you are capturing functional requirements as user stories, capture everything in the story form and adjust its state (or location in the backlog) as appropriate? To me, it seems like a single, unified method of expressing all requirements and acceptance criteria would make management of the requirements much easier to understand and mentally process.
    – Thomas Owens ♦
    Sep 12, 2011 at 0:50
  • It depends on size. Splitting acceptance criteria (which might include NFRs) out as separate stories is a good way of reducing story size if they are too big to work on. For NFRs like "must comply to security standards" I would rather not see them as a separate story - they probably apply to all work on an app so the story itself is never really done. Better expressed as definition of done or acceptance criteria.
    – Ben
    Sep 12, 2011 at 10:31
2

Action items are similar to the tasks within user stories, but they do need to be handled differently.

Often they are process improvements or other "meta" tasks that come out of sprint retrospectives: they don't directly add value to the customer so how can they be part of a story? Here are some examples:

  • Prepare training for new starter
  • Move codebase to new build system
  • Generate class documentation automatically during build
  • Give presentation on what was learned at recent conference

On the other hand, it is all "just work", so it's useful to represent these tasks visibly on the whiteboard rather than in a separate list somewhere.

I've put a couple of extra "pseudo-story" rows on my board for tasks like these, called Non-project work and Improvements and technical debt. The product owner doesn't have to care about them, and they don't score story points, but at least they are visible and the team can move them to Doing and Done as they would with any other task.

Improve this answer
2
  • 1
    For your pseudo-story rows, do you format these like stories? For example, "As a team member who could not attend the conference on X, I would like to see a presentation on lessons learned in order to improve my knowledge base" or do you just write "give presentation on conference" and assign it to the person/people who went to the conference? Part of me is curious if maintaining consistency across work item (stories, action items) is worth it.
    – Thomas Owens ♦
    Sep 20, 2011 at 10:35
  • No, the action items are like individual tasks, each of which we represent on a single sticky note. So one sticky note would just say "Give presentation on conference" and the assignee's initials. This is like a task in a story might be "Manually test this feature on Windows XP". The pseudo-story itself is the whole collection of action items. I don't think it would add much value to write it in the form of a user story (but if it does add value for you, then go for it!).
    – Paul Stephenson
    Sep 20, 2011 at 17:51
1

I agree with Aaron, that stories and tasks should not be used interchangeably. However, I do have a few comments:

The invest mnemonic is essentially a check list to run down while writing stories. Good stories are ones that generally meet all of the criteria within that check list. For example, you should strive to have stories that are independent (while being aware that sometimes it just is not possible). Just because a story depends on another "to be able to release the product" doesn't mean that the story can't be developed and tested separately.

If you wish to read a little more in depth about INVESTing in good stories, Kelly Waters has a nice series here: http://www.allaboutagile.com/invest-in-good-user-stories/

Don't forget about story Acceptance Criteria. Your example of a task imo is actually acceptance criteria:

As a user, I want this program to respond to {input X} within 1 second so that I can complete this task within the deadlines.

Acceptance criteria can be part of a single story and the story must meet this criteria to be considered done. You can also have such criteria at the project level in the form of a teams definition of done. All teams should have some form of a definition of done that each story should meet before it can be called done.

Improve this answer
2
  • Would you consider it valuable to express all requirements (functional and non-functional) in the same overall format, though? For example, if you are capturing functional requirements as user stories, also capturing non-functional requirements as user stories and perhaps changing their "done" status should it change through the implementation of other stories? For example, if implementing a functional story causes a non-functional requirement to no longer be met, moving that "story" back into the backlog. I wonder if it makes management and mental modeling of the requirements easier/clearer.
    – Thomas Owens ♦
    Sep 12, 2011 at 0:48
  • 1
    Honestly I think it depends on the team and the environment your are working in. Give it a try, just make sure you touch on it in a retrospective. The teams I have worked with have only written epics / stories (functional requirements) in the as a user...format. We've typically left non-functional requirements express themselves in the form of acceptance criteria / detailed tasks.
    – Jesse
    Sep 12, 2011 at 4:13

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.