User Stories and the 3 things that make them complete

A really good user story will have three things to make them useful and complete

• Who
• What
• Why
  

I’ve seen so many user stories that have the Who and What nailed, but they miss the Why. Adding the Why seems to be the hardest part, but it’s so useful for prioritization and for stakeholder understanding.


So what are these user story elements?

• Who = the primary actor. The Who can be generic like customer, user or specific such as specialized user of a system. The Who can also be a non user such as a server; I’ll give an example later.
• What = the action the primary actor wants to take.
• Why = the value or the reason the primary actor wants to do the action.
  

When writing user stories I’ll use standard phrases to ensure the completeness of the user stories

1. “As a” to identify the Who
2. “I want to” to identify the What
3. “So that” to identify the Why
   

So let’s write a few user stories as examples

1. As a customer (who) I want to add items to a shopping cart (what) so that I can purchase them (why)
2. As a server (who) I want to receive well formed xml (what) so that I can process XML without errors (why)

As I write this I found some proposals to switch the Who, What Why to Why, Who, What to provide the business value up front. It’s an interesting idea to try when you write your user stories.

User Stories and the 3 things that make them complete

Getting Started with Agile Project Management

I've recently read some discussions about how to get started with Agile Project Management. Its not hard to get started with Agile, however Agile project management is hard to sustain if you are not prepared for the issues that will arise. From personal experience there are a few things to tackle before adopting Agile Project Management. These ere education, training, finding a coach, and just getting started. The education part is pretty easy, there are some really good books that cover Agile Project Management and User Stories.

Books -I've read all of these Agile Project Management book and use them as a reference.

• Agile Project Management with Scrum


• Agile Estimating and Planning


• User Stories Applied

Certification - The Certified Scrum Master certification class is a great way to get some exposure to Scrum and learn about some common issues that beginners run into. Its even better to send several people on the team to the CSM class.

Coaching - Agile is hard, get an Agile Coach to guide you through the first project or at least the first few sprints. The value of the knowledge transfer and guidance will far outweigh the cost of the coach. The coach will know from experience what problems happen with new agile teams and can guide the team through the trouble spots

Just Get Started - I remember the very first step we took to adopt Agile Project Management. The development team was in a conference room with the product owner, we wrote 12 user stories and prioritized them. The simple step of getting requirements via user stories and prioritizing them into the product backlog was an eye opening experience for the team. At once the software development team understood what was important to the product owner and the product owner better understood what the software development team could do in the time period for the project. In the world of Agile this is a very simple step but it was the first crucial step to change the way the software development team interacted with the product owner. So, go read some books, get certified and take your first steps, its worth it.

Getting Started with Agile Project Management

Agile and User Interface Mockups

Some people will argue that user interface mockups smell of big planning and have no place in agile, I disagree. Let’s face it; it’s hard for a product owner to communicate to the software development team how a software product should look and work without pictures.

A product owner that has screen mockups to work with has a powerful tool to elaborate user stories. Pictures enhance collaboration and understanding by giving the software development team an alternate method of receiving software product requirements from the product owner.

From a QA perspective, the mockups serve as a guide for testing the user interface to ensure that the user interface is developed as requested by the product owner.

It gets tricky though when the user interface mockup illustrates product functionality covered by several user stories. The one easy way around this is to just add the user story number to the mockup and use themes.

Agile and User Interface Mockups

Focused delivery of value

Isn’t that what it’s all about? I was writing something else today about aligning resources and part of what I wrote was “focus resources on the high value deliverables for quick impact and realization of value”. Anything that gets in the way of this is a negative and removes value from o software development project. It seems so basic. In a nut shell this one sentence describes the goal of using agile project management methods.

Focused delivery of value

Agile Project Management for Globally Distributed Teams

What’s the perfect Agile team size? The typical Scrum team size is 5-7 people in one location with a dedicated product owner. This model has been proven out time after time. However, expand the team to 4 project managers, 50 people around the world, three different outsource vendors, three different languages, umpteen time-zones, a multitude of contractors, a team of product owners and you have a challenge. Standard, by the book Scrum will not work and we already know by experience that waterfall does not work.

What to do? Pick the best out of multiple project management methodologies and tailor a process that works for you. The goals are still the same, fast development, customer involvement, frequent feedback, and reduced waste. I’ve seen lots of experts write about standard scrum in small teams. I don’t see much written about large agile teams.

Scrum, What works for Globally Distributed Teams

• User Stories
• Short Sprints
• Test automation
• A commercial web based Agile PM tool
• Burn down charts
• Multiple Scrum Masters
• Customer involvement
• Prioritized product backlog
• Scrum of Scrums

Scrum, What does not work for Globally Distributed Teams:

• Daily standup meetings for the entire team
• A single product owner
• Sticky notes for user stories
• Developers adding tasks

Things to try: (I have and it works)

• A product owner team
• Three sprints per user story
  
• User story definition
• User story development
• User story QA/Test Automation/UAT
  
• Dedicated System Architects
• Multiple Project Managers - Scrum Masters
• Predefined tasks per user stories
• Multiple interacting scrum teams
• Be flexible with your approach

Agile Project Management for Globally Distributed Teams

Agile Project Management

Agile Project Management is growing in popularity as a method to more tightly involve the customer in the process of delivering a software product. Agile project management processes are a way to remove waste from all levels of product development and deliver value at a reduced cost.
The goals I had when introducing Agile were; fast development, customer involvement, frequent feedback, and reduced waste/cost.

Fast development: Achieved by delivering focused/concise user reviewed and approved user stories written in natural language thus reducing rework and waste. (Type B /C Sprint) Overlapping and concurrent sprints with defined teams doing specialized work keeps the development team pipeline full. It also keeps the customer involvement very high.

Customer involvement: Customer involvement is key to Agile, without frequent customer interaction the value gained by constant customer inspection and validation is lost.

Frequent feedback: An important agile process is short development cycles (three week iterations) with a demonstrable build at the end of each iteration. These builds are used to demonstrate functionality to the customer for approval or rejection. It’s much easier to change a three week cycle than a nine month development effort.

Reduced waste/cost: The agile process reduces cost and waste at many different levels. An important part of Agile is the frequent prioritization of user requirements to make sure the development team only focuses on what will be valuable to the customer. Prioritizing requirements results in a product that has immediate value without the clutter. Long term the result is lower product complexity and support costs.

Agile Project Management