What makes a good User Story

A User Story is intended to be a method of communicating business or application requirements between potentially nontechnical customers, team members who are not developers and the development / operations teams that must implement the required application or features. In other words, the User Story needs to be understood by all but still provide enough detail to allow the technical teams to actually understand the requirements and build the solution. So what makes a good User Story? A User Story should be a concise description of a piece of functionality that will be valuable to a user or owner of the software. To put it another way a User Story is a more universal way of writing a software requirement or deliverable.
A good User Story should describe [Who] the user of the feature is, [What] they need to do and [Why] they need to do it.  User Stories typically follow the format below:

As a [Who]
I need [What]
So that [Why]

or we could say

As a [Type of User]
I need to [Perform some action]
So that [business value received]

Following the INVEST acronym User Stories should have the following characteristics:
[I]ndependent Should not depend on any other User Story to be considered complete
[N]egotiable The delivery team needs to discuss User Stories before committing them to the “sprint” backlog. This discussion should happen during the sprint planning meeting
[V]aluable The completed User Story should add value for the customer. Customer should understand the resource and time cost associated with a given User Story based on Story Points estimated by the Product Owner and confirmed by the delivery team. This will help the customer and Product Owner decide if the value of the User Story is worth the cost in time and resources and prioritize the User Story accordingly
[E]stimable The User Story should be specific and granular enough that it can be completed within a single sprint. If the User Story is so complex that it cannot be completed within a sprint, then it is an Epic or Feature and should be broken down into small components / User Stories before being added to the backlog.  See this post on Story Point Estimation
[S]mall User Stories should be small enough that the specifics of the implementation of the User Story should not take more than 10 Developer (or Delivery Team) Tasks to flesh out
[T]estable The story should have Acceptance Criteria that describes what is required to consider the story complete. These Acceptance Criteria should present a clear path to testing requirements

Below is what seems to be a relatively simple example of a User Story

As a User
I need to register
So that I can manage my account

While the previous User Story seems pretty straight forward at first glance, as we analyze User Stories we may find that we have very large and complex Epics masquerading as User Stories.  In these cases it will be necessary to properly size or “Slice” the User Story or Epic into smaller chunks that can be completed in a single sprint.  See the Slicing User Stories 7 Methods Blog Series for more details.  I wouldn’t go as far as to say the previous User Story is Epic in nature but it could use a little clarification.  For example what exactly does account management entail?  What constitutes valid registration information?  We can break the story down to be a little bit more specific without getting technical.

As a new user
I need to register with my Facebook account
so that I can access members only content

As a new user
I need to register with my Google+ account
so that I can access members only content

As a new user
I need to register with my Email Address and Password
so that I can access members only content

As a new user
I need to add my address to my Profile
so that I don’t have to re enter it for every order

By breaking the story down we ensure that the tasks necessary to get the story to the Done will take less than the length of the Sprint.  We have describe the [What] in enough detail that the implementation team can complete the work without telling them [How] to do their jobs.
The [How] or the “technical details” are captured in tasks [Work Items] linked to a User Story in a Project Management / Work Item Tracking tool such as Jira or Team Foundation Services. Delivery Team task / technical details should be capture as specific tasks that can be completed in 2 hours or less. In a Continuous Integration environment as these tasks are checked into Source Control a build trigger would cause an automated build and automated test run. If any of the automated tests fail the system can automatically log a Defect and assign it back to the developer checking the code into source control. This rapid feedback keeps technical debt from slipping down the delivery pipeline.

Common User Story Issues
User Stories are too formal or contain too much detail – Keep the story simple and to the point. The detail should be fleshed out in tasks linked to the User Story during Sprint Planning
Technical tasks masquerading as stories Remember User Stories should be understood by the customer and the user as well as all non-technical stakeholders. Technical details are for the nested developer tasks.
The conversation is skipped – The team should evaluate User Stories provided by the Product Owner from the Customer in their Sprint Planning meeting. This is a good opportunity to play Planning Poker and make sure all team members are in agreement about the size and complexity of the User Stories planned for the coming sprint.
So remember keep User Stories simple and to the point, work out the details in the nested Delivery Team Tasks and be sure the team discusses User Story complexity, Story Points and Acceptance Criteria during Sprint Planning before committing the User Story to the Sprint Backlog.

Happy storytelling…

For more details on User Stories and estimating story points see the Story Points Estimation post



Slicing User Stories Method 4

Slicing by Acceptance Criteria
Many User Stories contain a number of explicit or implicit Business Rules usually represented as Acceptance Criteria. If a User Story is so large or complex that we could not complete it in a single sprint we can consider slicing the User Story by its Business Rules or Acceptance Criteria.
If we use a standard ecommerce website order entry process:

As registered customer
I want to purchase the items in my shopping cart 
So that my products can be delivered to an address I specify.

If we assume a standard order entry process and shopping cart, the following ‘Business Rules’ based stories would emerge:

As the site owner
I want to decline orders below 20 dollars 
because order processing outweighs profits;

As the site owner
I want to decline international orders
because credit card fraud and shipping expenses make these orders unprofitable;

As the site owner
I want to decrement inventory count when payment clears
so other customers see an accurate stock count;

As the site owner
I want to automatically cancel orders for which I have not received payment within 48 hours
so I can sell them again to other customers;

In most cases the Acceptance Criteria will give you a relatively close mapping to Business Rules. Since the Acceptance Criteria are typically used as the outline for Test Scripts this method aligns well with Behavior Driven Development or Acceptance Test Driven Development. Slicing the User Story in this manner allows us to focus on the Business Rule /Acceptance Criteria that is most important to the customer first. The customer may decide that simply placing a message on the orders landing page that states “orders below 20 dollars cannot be processed” will suffice. In the first release of the product, with limited traffic, it may be ok to manual cancel orders for which payment has not been received or manually decrement inventory when product is shipped. In any event the more we slice down a User Story the more specific we can get when discussing Acceptance Criteria as well as identifying Delivery Team Tasks. At the end of the day this more granular view of the User Story allows us to make much better delivery estimates and ensure a more accurate representation of the customers wishes. However, like Database Normalization there is a happy middle ground between too coarse and too granular. So find your balance.
Previous Method 3 – Slice by Test Case ******* Next Method 5 – Data Types or Parameters

Install Java Development Kit

To get started with Java Development and follow along with the ProDataMan Agile and DevOps samples and demos using Open Source tools you first need to download and install the Java Development Kit (JDK)

You can find the link to download the JDK for you environment here: http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html
Select your operating system and CPU type from the list. I am running Windows 10 on a x64 CPU

Once the download is complete launch the .exe to install the JDK.
Click Next, Next, Finish to complete the installation.

Once the installation is complete you will need to add an Environment Variable for the JDK and add it to the Path system variable.
On Windows 10 type System in the Start Menu and select System (Control Panel) not System Info.

In the System dialog select Advanced System Settings in the menu on the left this will bring up the System Properties dialog.
In the System Properties dialog select Environment Variables

In the Environment Variables dialog select New in the System Variables section
In the New Variable dialog enter JAVA_HOME for the Variable Name and the path to your JDK installation as the Variable Value

Click OK to save the changes to the new JAVA_HOME system variable.
In the Environment Variables dialog select the Path System variable in the System Variables section and click Edit.
Add %JAVA_HOME%\Bin to the end of the list and click OK

Now that the JDK has been installed and the Path System Variable has been updated we can verify the version of our installation from a command prompt.
Launch a command window by typing CMD in the start menu
At the command prompt type Java -version end press Enter
You should receive output similar to the image below.

Now we are ready to install Maven and Eclipse.
Check out the YouTube video of this demonstration below:

Slicing User Stories Method 3

Slice by Test Cases

Slicing User Stories by Test Case is useful when it is hard to break down an Epic based on functionality alone. With a large Feature or Epic, it is helpful to look at possible Test Cases as a way to break the Epic down into smaller chunks that can be completed within a single sprint. Analyzing which Acceptance Criteria Scenarios have to be checked to get the Epic to its Definition of done will provide a good framework for identifying manageable user stories.
Take an e-Commerce websites Order Entry Feature:
As a customer I want to Order the Items in my shopping cart
If we consider this functionality based on potential scenarios, we can break down the item into:
Test Case 1: If a customer is signed in Shipping Information from the profile is automatically added to their order
Test Case 2: If a customer is signed in Billing Information from the profile is automatically added to their order once the credit card verification number is confirmed
Test Case 3: If a customer is not registered or signed in they must manually enter their shipping information
Test Case 4: If a customer is not registered or signed in they must manually enter their billing information
Test Case 5: If a product in the customers shopping cart is out of stock it should be automatically added to their wish list
Test Case 6: Orders can be entered using a touchscreen monitor
Using this method for Slicing User Stories can actually help you apply the other methods implicitly. For example, by analyzing potential test cases, you will expose a number of business rules (#1, #2, #3, #4 and #4), (un)happy flows (#3, #4 and #5) and even input options (#6). Occasionally, Test Cases will be very complex due to the work involved in setting up and completing the tests. Once we have created a list of possible test cases we can prioritize based on frequency of use of the feature being tested.  If a Test Case is not high on the priority list (not very common) or does not present a high enough risk, a Product Owner could decide to shelve the feature for the time being and focus on Test Cases that deliver more value. In the case of a very complex Test Case, we may decide to simplify (or Slice) the Test Case to prioritize and complete the most urgent feature elements. In any case the most relevant Test Cases can be easily translated into User Stories and added to the Sprint Backlog or Product Backlog.
Previous Method 2 – Slice by Workflow Steps *******Next Method 4 – Slice by Business Rules

Slicing User Stories Method 2

Slicing by Workflow Steps

Most anything that we would add to a solution and describe in a User Story is a process that has some sort of workflow.  In most cases these workflows can be broken down into individual steps. A large User Story with several workflow steps can be broken down into smaller users stories based on these workflow steps.

Consider the following User Story for an ecommerce website.

As registered customer I want to purchase the items in my shopping cart so that my products can be delivered to an address I specify.

If we assume a fairly standard shopping cart and order entry process, we could identify the following steps:

As a registered customer I want to log in with my account so I don’t have to re-enter my personal information every time;
As a registered customer I want to review and confirm my order, so I can correct mistakes on my order before I pay;
As a registered customer I want to pay for my order with a credit card, so that I can confirm my order;
As a registered customer I want to pay for my order with a wire transfer, so that I can confirm my order;
As a registered customer I want to receive a confirmation e-mail with my order, so I have proof of my purchase;

As you see, there was more to this seemingly simple User Story than was originally apparent.  By breaking the User Story down into its individual workflow steps and considering the different options that a user may use to pay we make the customers intentions much clearer to the developer implementing the functionality.

We must keep in mind the reason for creating User Stories in the first place; to engage the customer in conversation about desired functionality and clarify expectations before passing requirements on to the delivery team.  The more granular our User Stories, the more specific our discussion of desired functionality and Acceptance Criteria can be.

Knowing the details of the workflow the team can prioritize the functionality based on business value.  For example perhaps in the first release we only allow customers to pay with a credit card and we send the order confirmation manually or perhaps customers are required to enter their address information manually until saving addresses is available in release 2.

In any event having more granular user stories allows the delivery team to have detailed discussions about the desired functionality without missing key workflow steps or Acceptance Criteria.

Slice dice and discuss!

Previous Method 1 – Slice by Happy vs Unhappy Flow ****** Next Method 3 – Slice by Test Scenarios

What is Continuous Delivery

First let’s talk about the acronyms CI, CD and CD…  This whole CI / CD thing causes all sorts of confusion.  First CI is Continuous Integration, for a definition see my previous post here: What is Continuous Integration.  CD, now that’s a little trickier…  CD is either Continuous Delivery or Continuous Deployment depending on where you are in the pipeline. So then what is Continuous Delivery really? The textbook definition of continuous delivery is as follows:
Be ready and able to deploy any version of the solution to any supported platform at any time.
But what does that mean Exactly? Before we break down the definition of Continuous Delivery lets list a few key enablers.

  • Test Driven Development
  • Developing on Trunk
  • Implementing Feature Flags
  • Automated Acceptance Testing
  • Configuration Management
  • Automated Deployment

As we break down the definition of Continuous Delivery we will see where each of these processes helps to enable Continuous Delivery.
First let’s talk about being ready and able.  If your boss or a client were to come to your team’s work area right now and say “hey, you geeks deploy that solution right now!” how long would it take you to get it into production? Will it take 15 minutes, an hour, 8 hours, 48 hours or more? If we want to be “ready and able” to deploy at any time we can’t have a bunch of incomplete features, untested code, branches that need to be merged and bugs that need to be fixed. Since there will always be times that a feature is not complete because the developer is still working on it we can use Feature Flags. Feature Flags disable, hide or restrict access to code when committing changes to source control so that the solution can deployed at any time. For example, imagine you are adding a new login functionality to your solution. The developer has created the login page but the login database has not yet been created therefore the login page will not work. We can use Feature Flags to commit the new login page to source control while keeping the login feature disabled. Using Feature Flags also to develop changes without branching because the primary reason for branching is to avoid changes breaking the codebase and restricting our ability to deploy. We call this approach Developing on Trunk (get it no branches it’s just the trunk)  To make sure that we can deploy quickly after changes are committed to source control we need to make sure that the code is already well tested automatically as its committed. We call this technique Continuous Integration but in order to have the tests available at commit we must also implement Test Driven Development also known as Test First Development. To ensure that we can repeat the deployment process on demand and in a reasonable amount of time Configuration Management must be automated as well to a point that we can reconfigure servers as settings files stored in Source / Version Control. Configuration Management avoids issues like Configuration Drift, Snowflake Servers and Inconsistent Environments. Configuration Management also allows us to maintain installation and configuration settings in Source / Version control for all previous versions enabling deployment of “any supported version to any platform”. Lastly while we just need to be “ready and able” to deploy we still need to ensure that deployment is not a painful or high-risk process. Deployment needs to be a push button, single click, low risk event. To accomplish this deployment must be automated. Automated Deployment can be achieved in many different ways from batch files and scripts to release management software. The way you automate is as import as the fact that you actually do Automate Deployment.
As you begin your journey of Continuous Improvement to your Solution Delivery Pipeline remember this “You do not need to solve all the world problems in the first iteration”. Make incremental improvements to your current process, collect feedback and integrate that feedback into the next iteration to Continuously Improve the Solution and the Process.

What is Agile Marketing

I am a firm believer that everything can and should be Agile! The days of analysis paralysis should be long behind us. Our customers and their attention spans move at internet speeds and you have 3 clicks or less to get their attention. Agile software delivery strives to deliver business value to customers quickly while minimizing risk and defects while Agile Marketing is essentially the same idea where the business value is timely and relevant information about our product / service offerings to new and existing customers. Defects or campaigns that do not generate interest and conversions should be quickly identified, modified and / or eliminated in favor of better performing campaigns.

Agile Marketing Manifesto (interpreted) :

Individuals and Interactions over Processes and Tools
Measurement and Data over Opinions and Conventions
Authentic Engagement and Transparency over Official Posturing
Rapid Iterations over a Few Large Bets
Two-way Conversations over One-way Interruptions
Intimate Customer Tribes over Impersonal Mass Markets

Below, we have compiled are a few Agile Marketing related resources:

Intro to Agile Marketing in 2 minutes

The title of this video speaks for itself… 2 minutes – let’s go!

The Agile Marketing Manifesto


Here, the author discusses newways to create customer value for organizations through the new marketing approaches. These approaches come from a combination of Agile Marketing manifestos featured in a blog post by Travis Arnold. Values that have been highlighted include collaboration, adaptive campaigns, customer discovery, and more.

A collection of Agile Marketing Manifestos

Roundup: Agile Marketing Manifestos

As referenced above, this article compiles a host of different Agile ideas and principles, and in doing so points out the differences between them. The contrast between comprehensiveness, and simplicity are reviewed, and the limitations of each are discussed.  In addition, he gives feedback on each manifesto, focusing on what is most important from his point of view.  Different Agile practitioners often have different views, so it is valuable to look at the simple breakdowns of the initial framework that embodies what Agile Marketing is all about.

Implement Scrum for Digital Marketing

Agile Marketing: How to Implement Scrum for Digital Marketing

This article looks at Agile as a marketing methodology, separating it from its roots in software development and applying the practices to marketing campaigns. Digital marketing teams face different challenges than software development teams, but conceptually, many of these issues are very similar. Agile management practices that are data driven, quantitative, and iterative can be applied to marketing campaigns to mitigate risk, and help them operate more effectively. Here, the parallels are pointed out, and the problems faced in software development are adapted to a digital marketing teams point of view.

Agile Marketing a step by step guide
This is another great article that focuses on engaging in innovative new ways to meet customers’ needs more effectively through Agile marketing practices. Again, it looks at Agile from a marketing perspective, and gives a step by step overview of how to implement it properly. It covers core concepts, such as evaluating results to improve data driven solutions, deploying tests quickly, and rapidly iterating processes to achieve targeted goals. Not only does it describe and define the concepts of Sprints, designing tests, and customer first methodology, this article also provides practical and effective tips to do so.

Airline club membership Is it worth it

On an early Monday flight I pretty much have the whole United club to myself…

If you have ever thought about United Club membership before I offer a little food for thought:

If you spend as much time at the airport as I do (or even way less) think of club membership in terms of free “faster” Wifi, free drinks, soups and salads as well as a relatively quiet space to relax or work and wait for your delayed flight.

Imagine this scenario:
You have an hour and 25 minute wait for your next flight or enough time to have 2 glasses of wine a bowl of soup (or 2) and a salad. While enjoying your wine and eating your soup and salad you return a few emails and finish that proposal on your laptop. What’s that your flight was canceled and you need to talk to customer service but so do the other 247 people on your flight? No problem go to the club and talk to customer service there “members only”.
So how much does all of this cost?
First let’s do the math…
2 airport glasses of wine – $18
1 airport bowl of soup – $9
1 airport salad – $12
Quiet workspace with space for laptop and faster wifi – $priceless

For a grand total of $39 actual dollars per leg of your trip plus at least $50 worth of less noise and airport DRAMA. What is your peace of mind worth??
So you get stuck on that flight from SFO to DCA and have to go through ORD because you booked last minute. That’s $39 at SFO $39 at ORD and $39 at DCA (Because it’s better to wait for your bags in the club with a free drink in your hand) or $117 each way. A grand total of $234 round trip. Did I mention you get a plus 1?
The membership is $550 which sounds expensive until you do the math. If you travel for work at least once per month club membership represents a cost savings. Or if you travel for fun with a companion more than 4 times per year or if you just drink and snack A LOT. You have a full year to eat and snack your way to your $550 membership fee.

The Increasing Cost of Technical Debt

The cost of defects increases exponentially as they slip down the delivery pipeline a shift left in quality, security and stability goes a long way toward reducing costs. We must make a shift left in quality, security and stability by surfacing defects earlier in the Delivery pipeline as defects get exponentially more expensive as they slip down the pipeline. A defect caught after development in quality assurance is about 15x costlier than a defect found in design.

The Increasing Cost of Technical Debt
The Increasing Cost of Technical Debt

From a development perspective, a defect found during implementation is 6.5x costlier than if it were found in design but still about half the cost of finding the same defect in QA. If we have so many gaps in our process that a defect makes it from design, through implementation and QA and somehow finds itself in production the cost is 100x higher than finding that same defect in design.
A more elusive fact we must also take into account is the soft costs associated with the very public statement that the dev (and quality assurance) team “is a joke” as colleague of mine would say. All joking aside this is a team effort it is not only the developers fault but also QA, infrastructure, release management and anyone else responsible for any part of the pipeline. We sink or swim as a team and quality is everyone’s responsibility. If we deliver a crappy piece of software and the stock tanks and the company goes out of business we are ALL out of a job. Reputation cost is a little difficult to quantify but suffice it to say that releasing software riddled with defects and poor user experience does not build confidence in your team’s ability to deliver quality solutions to its customers.
Implementing processes such as Test-Driven Development, Continuous Integration and Automated Acceptance Testing / Behavior Driven Development can help teams make that “Shift Left” in quality that reduces the cost of their debt. As teams will typically incur from 10% – 30% technical debt to new work ratio per sprint it’s a good idea to do everything we can to find the defects and reduce debt before is slips down the pipeline towards Maintenance / Production where the costs skyrocket.