Project Management

User Story-based Project Planning

Merging this with David Allen's ideas of Project Planning. He says there are five phases:

  1. Establish Purpose
  2. Clarify Outcome (Vision)
  3. Creatively Brainstorm for ideas (who? what? how? ropes & fuels…)
  4. Organize into a structure (planning)
  5. Take Action (do it!)

Folding this in to an agile frame-of mind, some thoughts come to mind:

  • We've been really good about expressing Outcomes in User Stories (because that's, minimally, what they do). "As a Customer, I can remove an item from my cart without losing my place on the screen (referring to browser "refresh"), so that I have a better/cleaner/more intuitive user experience on the site." This is a great example of a clear outcome. But is there enough in her about purpose? Probably, the "so that" portion hits that. Good.
  • How about actions? When do you need to detail these out?
    • One obvious answer is when the next action to take is not clear.
  • If a User Story is not assignable to one person, then it is too broad/coarse and needs to be broken down into more fine-grained outcomes.
    • "As an ABC Architect, I want to know the technical differences between JBoss and WAS CE, so that I can vote on which platform we should build our applications on." =>
      • "As an ABC Architect, I want to know what options are available for clustering in JBoss and WAS CE."
        • "…clustering Servlets…"
        • "…clustering EJBs…"
        • "…clustering JNDI…"
      • "As an ABC Architect, I want to know what deployment looks like for JBoss and WAS CE."
      • "As an ABC Architect, I want to know how easy/difficult it is to build and deploy EARs in our environment."
      • (brainstorm what all the core features are of an application server).
    • Dependency Catalog
      • Could have had made it two choices:
        • Which of these features do you use? (come up with and provide a check-list, per Application)
          • That check list would be WAY too big if we just opened the manual.
        • We discovered the use of these features.

"Moving Parts"

Every project has some locus of movement: moving parts. One way to grasp a large project is to think and talk about status and movement of those parts.

  • Status =
    • What's the current action(s) taken?
    • Is the next action-step known?
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License