Acceptance Test Automation with Cucumber / SpecFlow in Visual Studio

Acceptance Criteria, Test Automation and Gherkin

What do Acceptance Criteria, Test Automation and a Cucumber have in common? Well for the uninitiated in may seem that these 3 things have nothing in common however if you are an “Agilist” or Test Automation specialist than you are probably very familiar with the similarities. Let’s start with the Cucumber specifically the Gherkin. The Gherkin as it happens is the most common type of cucumber used to make pickels. Gherkin is also the language used to Automated Acceptance Tests in a tool called Cucumber. Acceptance Criteria are the conditions for success for a new feature or part of a feature being added to solution. If the Acceptance Criteria is written in Gherkin format most of the heavy lifting of Test Automation has already been done. To automate acceptance tests in Visual Studio we use the Visual Studio version of Cucumber: SpecFlow. To get started using Gherkin Acceptance Criteria to Automate Acceptance Testing the Visual Studio IDE needs to be configured to use the Cucumber / SpecFlow extension.

Create a Virtual Machine in AWS install SpecFlow Extension in Visual Studio Community Edition and create an Automated Acceptance Test for a basic Stack object. Detailed Step By Step Instructions below video

Install SpecFlow Extension for Visual Studio

  1. In Visual Studio 2019 Community Edition
  2. In the Launch dialog choose Continue without code
    VS 2019 Continue without code
    VS 2019 Continue without code
  3. In the Extensions Menu Select Manage Extensions
    VS 2019 Manage Extensions
    VS 2019 Manage Extensions
  4. Select Online from the Navigation menu
  5. In the Search box type “SpecFlow”
  6. Select SpecFlow for Visual Studio 2019 and click Download
    VS 2019 Install SpecFlow Extension
    VS 2019 Install SpecFlow Extension
  7. Click Close to close the Manage Extensions dialog
    VS 2019 Close Visual Studio to complete SpecFlow Extension Installation
    VS 2019 Close Visual Studio to complete SpecFlow Extension Installation
  8. Exit Visual Studio
  9. Click Modify in the VSIX Installer dialog
    VSIX Installer
    VSIX Installer – Modify
  10. When Installation completes click Close in the VSIX Installer dialog
    VSIX Installer
    VSIX Installer – Installation Complete
  11. Restart Visual Studio

Note: Visual Studio will not Install the Cucumber Extension until all Visual Studio windows are closed.

Create a Unit Test Project to Map Acceptance Criteria

  1. In order to Add Gherkin Feature Descriptions we will need to add a Unit Test Project.
  2. In Visual Studio from the File menu select New Project
  3. In the New Project Dialog under Language select C# under Platform select Windows under Project Type select Test
  4. Select Unit Test Project (.NET Framework) and click Next
    Create new Test Project
    Create new Test Project
  5. Name the Project Stack App Acceptance Tests
  6. Name the Solution Stack App
  7. Click Create

    Configure new Project and Solution
    Configure new Project and Solution names
  8. In the Solution Explorer
  9. Right Click UnitTest1.cs and select Delete
  10. Right click the Project and select Add New Item
  11. Select the SpecFlow folder on the left
  12. Select SpecFlow Feature File
  13. Name the File StackAppFeatures.feature
  14. Click Add

    Create new Feature File
    Create new Stack Feature File
  15. In the Solution Explorer select StackAppFeatures.feature
  16. In the Properties windows remove SpecFlowSingleFileGenerator from the Custom Tool Property
    Remove Custom Tool Property value
    Remove SpecFlowSingleFileGenerator from the Custom Tool property

Note: The Custom tool error will disappear once the SpecFlowSingleFileGenerator text is removed from the Custom Tool Property of the StackAppFeatures.feature file.

Add SpecFlow NuGet Packages to Test Project

  1. Right click the Stack App Acceptance Tests Project
  2. Select Manage NuGet Packages… from the Menu
  3. In the NuGet Stack App Acceptance Tests window select Browse form the menu
  4. In the Search (Ctl+L) box type SpecFlow and press enter
  5. Select SpecFlow by TechTalk
  6. In the Detail window to the right click Install

    Install SpecFlow NuGet package
    Install SpecFlow NuGet package in Test Project
  7. In the License Acceptance dialog click I Accept

    License Acceptance - I Agree
    License Acceptance – I Agree to accept license terms
  8. Select SpecRun.SpecFlow
  9. In the Detail window to the right click Install
  10. In the License Acceptance dialog click I Accept
  11. In the Search (Ctl+L) box type SpecFlow.Tools and press enter
  12. Select SpecFlow.Tools.MsBuild.Generation
  13. In the Detail window to the right click Install

Step Definitions

In the Solution explorer select StackAppFeatures.feature and replace the Math feature (User Story) and Acceptance Criteria with text below:

Feature: StackAppFeatures
    As a User
    I need to Stack stuff
    So that I can move it around

@EmptyStack
Scenario: IsEmpty should be true
Given An Empty Stack
When I check IsEmpty
Then IsEmpty should be “true”

@NonEmptyStack
Scenario: IsEmpty should be false
Given A nonEmpty Stack
When I check IsEmpty
Then IsEmpty should be “false”

@PushTests
Scenario: Push Check IsEmpty
Given A Empty Stack
When I Push “Bugga Boo” onto the Stack
And I check IsEmpty
Then IsEmpty should be “false”

@PushPopTests
Scenario: Push Gets Popped
Given An Empty Stack
When I Push “Item 1” onto the Stack
And I Pop a value off the Stack
Then The result should be “Item 1”

@PushPeekTests
Scenario: Push Gets Peeked
Given An Empty Stack
When I Push “Item 1” onto the Stack
And I Peek at a value on the Stack
And I check IsEmpty
Then The result should be “Item 1”
And IsEmpty should be “false”

The purple text indicates that the Gherkin statement does not yet have associated step definitions. We’ll use the Code Generations tools in the SpecFlow extension generate the step definitions from the Gherkin Acceptance Criteria.

  1. Right click on Given an Empty Stack and select Generate Step Definitions
  2. In the Generate Step Definition Skeleton – SpecFlow dialog click Generate

    Generate Step Definitions
    Generate Step Definitions
  3. In the Select target step definition class file dialog accept the defaults and click Save

    Accept Default location for Step Definitions class
    Accept Default location for Step Definitions class file

Feature Implementation – Test First

Now we will replace the ScenarioContext.Current.Pending(); placeholder code in each of the Given…When…Then… functions in the StackAppFeaturesSteps.cs class file with calls to our code under test

  1. In the Solution Explorer select the StackAppFeaturesSteps.cs class file
  2. Add the following code to the StackAppFeaturesSteps class
    Stack stack;
    String _actual;
    Boolean _isEmpty;
  3. In the public void GivenAnEmptyStack() function replace the ScenarioContext.Current.Pending(); with the code below
    stack = new Stack();
  4. Replace the ScenarioContext.Current.Pending(); code in the GivenANonEmptyStack function with the code below
    stack = new Stack();
    stack.Push(“Hello, World!”);
  5. Replace the ScenarioContext.Current.Pending(); code in the WhenICheckIsEmpty function with the code below
    _isEmpty = stack.IsEmpty();
  6. Replace the ScenarioContext.Current.Pending(); code in the WhenIPushOntoTheStack function with the code below
    stack.Push(p0);
  7. Replace the ScenarioContext.Current.Pending(); code in the WhenIPopAValueOffTheStack function with the code below
    _actual = stack.Pop();
  8. Replace the ScenarioContext.Current.Pending(); code in the WhenIPeekAtAValueOnTheStack function with the code below
    _actual = stack.Peek();
  9. Replace the ScenarioContext.Current.Pending(); code in the ThenTheResultShouldBe function with the code below
    Assert.AreEqual(p0, _actual);
  10. Replace the ScenarioContext.Current.Pending(); code in the ThenIsEmptyShouldBe function with the code below
    Assert.AreEqual(Boolean.Parse(p0), _isEmpty);

Now that we have our tests we can use code generation tools to create the class under test. At this point we will also have 5 syntax / reference errors, we will resolve these in the next steps.

  1. In the solution explorer right click Solution ‘Stack App’ (1 of 1 project) select Add > New Project
    In the Solution Explorer you should now see the Stack Utility project
    Add new Class Library project
    Add new Class Library project
  2. In the Solution Explorer select the StackAppFeaturesSteps.cs class file
  3. In the StackAppFeaturesSteps.cs class file hover the mouse over the Stack type with the red squiggles
    In the Quick Actions menu (The lightbulb) select Generate type ‘Stack’ > Generate new type…

    Generate Stack Type
    Use Quick Actions to Generate Stack Type
  4. In the Generate Type dialog select Stack Utility from the Project dropdown, select the Create new file radio button and click OK
    Note:
    the red squiggles under Stack are now gone
    No more red Squiggles
    Stack exists – No more red Squiggles
  5. In the StackAppFeaturesSteps.cs class file hover the mouse over the call to the stack.Push method and select Generate method ‘Stack.Push’ from the Quick Actions menu
    Generate Push method
    Use Quick Actions to Generate Push method
  6. Repeat the same process for the IsEmpty, Push, Pop and Peek methods
  7. In the StackAppFeaturesSteps.cs class file hover the mouse over the Assert in Assert.AreEqual and select using Microsoft.VisualStudio.TestTools.UnitTesting; from the Quick Actions menu
    Note: You may now run the tests and see them fail
  8. From the Test menu select Run > All Tests
    Note:
    In the Test Explorer that of 6 Tests 3 failed. Only 5 were actual tests 1 was a SpecRun delay for the evaluation version. 3 Failed and the 2 Tests are ignored. The ignored tests call methods that were already tested and failed in this test run.
    Run the Tests and see them Fail
    Run the Tests and see them Fail

Now that class skeleton has been created, we can implement the 4 methods, IsEmpty, Push, Pop and Peek.

  1. In the Solution Explorer select the Stack.cs class file in the Stack Utility project
  2. In the Stack class create a new stack variable of type ArrayList by adding the code below:
    ArrayList stack = new ArrayList();
  3. Hover the mouse over the ArrayList type and select using System.Collections; from the Quick Actions menu
  4. In the Push method replace throw new NotImplementedException(); with the code below
    stack.Insert(0,v);
  5. In the IsEmpty method replace throw new NotImplementedException(); with the code below
    return stack.Count == 0;
  6. In the Pop method replace throw new NotImplementedException(); with the code below
    String result = stack[0].ToString();
    stack.Remove(0);
    return result;
  7. In the Peek method replace throw new NotImplementedException(); with the code below
    return stack[0].ToString();
    Note:
    You may now run the tests and see them pass
  8. From the Test menu select Run > All Tests
    Note:
    All test should display a green check mark indicating a pass.
    Run the Tests and see them Pass
    Green = Good Red = Bad – Run the Tests and see them Pass


    Now that we have the Step Definitions (Glue Code) defined adding new Automated Acceptance tests is a simple a pasting in new Gherkin statements.  If the Product Owner adds new Acceptance Criteria to a user story we can simply copy and paste from the Work Item Tracking (Project Management) tool into our Feature file and we are done.  No new coding.  For example the Gherkin statement below can simply be added to the feature file with

    @MultiPushPopTests
    Scenario: Multi Push Pop
    Given An Empty Stack
    When I Push “Item 1” onto the Stack
    And I Push “Item 2” onto the Stack
    And I Pop a value off the Stack
    Then The result should be “Item 2”

no additional changes necessary.

Advertisements

Staging and Committing Changes in Git and GitHub

Staging Files
As we generate new solution artifacts they need to be added to the repository, integrated with work by other team members and tested to ensure that no defects were introduced by our changes. Until we add the files to the repository they are considered untracked files even though they are present in a folder in the repo. Simply creating files in the folder structure of the local repository is not sufficient.


Create Echo.java in local repo folder structure

After creating a new file, we can use git status to check the status of files in the repository’s directory structure. Untracked files will be displayed in red. Red bad Green good!


Use git Status to see untracked files

Depending on the number of files we have created we can use git add with various options to track one or more untracked files. If we create a single file (or a short list of files) we can use git add <filename(s)> to Stage a particular file or list of files


Stage single file or list of files with git add <filename(s)>

If we create multiple files in a single directory we can use git add . to Stage all files in the current directory but not sub directories. We can use git status at any time to determine if there are any untracked files or uncommitted changes in the local repository.


Create multiple untracked files and check status

Once we have determined that there are 2 untracked files and tracked file with a changes to be committed we can use git add . (git add –all) to add all track all new files in the current directory (or all files in current and subdirectories)

Stage all files in current directory
Git add .

If we create multiple files in multiple subdirectories we can use git add –all to stage all files in the directory tree with a single command

Committing changes to the Local Repository
Once we have created or edited files and Staged the changes then we can commit the changes to the repository. However, if we attempt to commit without authenticating against the repository we will get a warning message


Please tell me who you are

We can add the email and username info using the git config command


Use git config to add email and user name

Committing changes to the Local Repository
If we attempt to commit without adding a commit message we will be prompted to enter a commit message in the dreaded vim editor as in the image below. If you find yourself in this editor, enter your message then press <esc> to exit edit mode then type 😡 <enter> to exit the editor


Enter Added Echo Util Class, Unit and Acceptance Tests

Adding a Commit Message

Once we have added our commit message and have pressed <esc> then typed 😡 <enter> to save and exit the editor we will then see our commit message followed by details about the files committed to the repository as in the image below.


Commit complete

Pushing Changes to a Remote Repository
In order to share our changes with other team members we need to push our changes to a remote repository. With a small team and little to no branching pushing changes to a remote repo is as simple as running git push origin master. This command pushes changes from the current branch in the local repo to the master branch of the remote repo


git push origin master

The get push origin master command only works if you cloned your remote repository to the local repository or if you have configured the remote repo in advance. Even if you cloned or configured the remote repo in advance if you are not already logged into the remote repo you will be prompted to log in when you execute git push origin master


Authenticate to remote repo for push to complete

Once you have authenticated, the commit will complete and a status message will be displayed showing the number of files committed as well as the source and destination branch.


Push complete

In the next post we will clone this remote repo to a new local repo on a different computer pull the changes add a couple of new files commit and push our changes before we move into branching and merging.

Creating a Git Repository

There are a few ways to create a Git Repository but before we talk about How let’s talk about Why.
Why do we need a Git Repository or any Repository for that matter? And What is a Git Repository anyway? In its simplest for a Git Repository is simply a folder that contains files that we want to keep track of. As changes are made to the files the modifications and different versions of the files are tracked and changes are committed to the repository. This is very useful when there are many different team members working on the same set of files. For this reason, tools like Git are commonly referred to as Version Control systems. Historically systems such a Git, SVN and Subversion have been used to store Source Code for software applications so they have also been referred to as Source Code Management SCM or Software Configuration Management Systems. However, with the recent push to streamline Software Delivery Life Cycles (SDLC) there has been a move to place ALL solution related artifacts in Version Control. This allows for configuration of Continuous Integration, Automated Testing, easier automated deployments and simplified scrips.

So that makes the why do we need a Git Repository question easier to answer. A Git repository provides a central source of truth as to the current, tested and ready to deploy version of the application. A Git repository also provides a central source from which to build and deploy our solutions from as well as providing the ability to isolate changes made to different features or by different developers to their own isolated branch of the repository.

So now that we know what it is and why we need one lets look at how to create a Git Repository.

Git Init

If we are starting a brand new project and do not yet have a repository we can convert and existing directory into a repository using the Git Init command.
Git Init initialized the directory as a Git Repository and creates a hidden folder called .Git as a sub directory of the directory being initialized.

Git Clone

If we already have a remote repository in GitHub we clone that repository to create a local workspace with files we can edit.

GitHub
GitHub

Cloning a repository is a fast way for new team member to quickly get a new workstation setup and start being productive immediately.

Simply copy the URL of the Remote repository you wish to clone then run git clone <past URL here>. Depending on the size of the repository the cloning process takes a matter of seconds.

Once you have initialized or cloned your repository you can then begin to add files edit and commit your changes. See the next post in this series for details on adding files and committing staged changes.

Slicing User Stories Method 6

Slicing by CRUD or ISUD (AKA Slicing by Operations)

Any User Stories involving a managed entity, such as a Customer, Order, Employee or Product, will almost always require some level of management functionality.  This management functionality will provide the ability to perform a number of operations including at a minimum operation, such as Create, Read, Update or Deleted.  These operations are commonly referred to as CRUD but that is such an unfortunate acronym as it sounds like something you get between your toes…  Not to mention the fact that in most Relational Database systems such as MySQL and Microsoft SQL Server the operations are actually called Insert, Select, Update and Delete making the acronym ISUDISUD sounds better, soapy and clean to wash away the CRUD between your toes.  So forever more on this site CRUD operations will be referred to as ISUD operations!
ISUD operations are very prevalent when functionality involves the management of entities, such as products, users or orders:
As a Specialty Kite Maker
      I want to manage Kites in my ecommerce website
So I can update Kite details and pricing info if it is changed

If we consider the ISUD typically associated with Product management, we can derive the following more specific and granular User Stories:

As a Specialty Kite Maker
I want to add new Kites to my product list
So customers can purchase them;


As a Customer

     I want to view a list of Kites available for purchase
     So that I can buy one;

As a Specialty Kite Maker

     I want to list the Kites in my product list
     So I know what Kites are currently in stock;

As a Specialty Kite Maker

     I want to update existing Kites in my product list
     So I can adjust for changes in Kite details and pricing info;

As a Specialty Kite Maker

     I want to delete Kites from my product list
     So I can remove Kites that I no longer sell;

As a Specialty Kite Maker

     I want to hide Kites in my product list
     So they cannot be purchased for the time being;

When discussing this method, the question often becomes, “do these more granular User Stories actually provide business value?”.  Is our solution really useful if we cannot update or delete products from the system?  If we consider that in the current scenario we are dealing with a “Specialty Kite Maker” odds are there are a limited number of Kites and Kite Accessories that will be in the product list.  If this is the case then adding, editing or deleting the Kites could be done manually through a database management tool like SQL Server Management Studio for the first few Sprints.  So, for the first Sprint we may just add the list (Select) functionality to support customer purchases and delay the other Update, Delete and Insert User Stories for a later Sprint.  This way we get business value sooner by minimizing “Work In Progress” (WIP) we are able to increase delivery date confidence and deploy only features necessary to deliver value to the customer.  In this scenario, the lack of Insert, Update and Delete functionality will not be noticed by the customer because these are admin only features therefore we deliver just the customer facing User Stories.  This allows us to get to market faster and begin collecting customer feedback while we work to complete additional features.  In the case of discontinued or deleted Kites it may be easier to simply add a checkbox that allows the Kite Maker to mark an item as discontinued or deleted.  This approach may keep the record in the database but simply hide it from the customer view making it easier to implement than an actual Delete operation that may require additional operations to enforce referential integrity.
In short if we break the User Story down by operation we can implement only those operations that provide immediate business value in early Sprints and add other more specific stories once the base functionality is deployed to customers and providing them with “Value”.  “Customer Value” = “Business Value” which of course in almost every case translates to “Business Revenue” to pay for all of the Solution Development.
Slicing User Stories – Method 5 ***** Slicing User Stories – Method 7

Slicing User Stories Method 5

Slicing by Input Parameter (Datatypes)

In most cases a business process or whatever function that the new feature is intended to automate requires some data to perform its actions.  For the sake of this discussion we will refer to this data as Input Parameters.  Data of different types in most cases will need to be processed differently.  For example, a search for a customer’s last name would most likely require a String Comparison against the LastName field in a database while a search for a customer by their Customer ID would require an Integer Comparison against the CustomerID field in a database. Some User Stories can be split based on the datatypes they return or the parameters they are supposed to handle.

Take, for example, a search function for a standard ecommerce website:

As Customer

I want to search through available products
So I can view their details and order them;

Since there are potentially many different ways a customer might want to search for a product that they need or have previously ordered, each one of these search methods could be considered as a unique User Story:

As a Customer
I want to search for a product by the order date
So that I can find products that I have ordered before;

As Customer
I want to search for a product by its Product Id
So that I can find a product that I am familiar with;

As Customer
I want to search for products within a Price Range
So that the search results are relevant;

As Customer
I want to search for products by Color
So that the search results are more relevant;

As Customer
I want to search for products by Category
So that the search results are more relevant;

As we begin to think on a more granular level about the search function we can more clearly understand the kinds of search criteria the customer might be used. This allows us to more accurately implement the customers desired functionality, but it also allows a Product Owner to make decisions about priority within the feature and not just at the story level. For example, with just a few products in a new ecommerce web application paging 10 products at a time may not be necessary. Or maybe some of the search functionality can be implemented in a simplified manner for the time being.  Another example is breaking down the User Story based on how the returned data is displayed.  Perhaps our ultimate goal is to have sales results and product ratings displayed as beautiful 3D charts and animated graphics dynamically produced based on real-time sales data.  But for the first release the sales manager will simply import the sales data into excel and manually export 3D charts and graphs from excel on a weekly basis.
Slicing User Stories – Method 4 ***** Slicing User Stories – Method 6

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 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

DevOps Key Metrics

What I find most compelling about the DevOps metrics listed below is the fact that control of almost all of the metrics can be gained by mastering the first metric in the list. The metric that seems to tame all others is the Number and Frequency of deployments / software releases. If we strive for the seemingly extreme goal of 10+ Deploys per Day the milestones that we much achieve to reach this goal end up covering all of the remaining metrics. For example, if we are able to deploy 10 times per day without losing or pissing off every single one of our customers we must have reduced the volume of defects, number and frequency of outages as well as cost of those outages. As the story goes in order to deploy 10 times a day most everything in the delivery pipeline needs to be automated therefore automated testing should reduce the Number of Defects and the cost associated with fixing them. By the same token if the deployment is automated the Number and Cost of Resources associated with deployment should be reduced. Lastly in order to deploy 10 times during a normal workday of 8 hours (480 minutes) our deployments must be done every 48 minutes. If we intend for our customers to actually use our solution the actual deployment must take significantly less than 48 minutes! As a result, Mean Time to Recovery and Mean Time to Change must go down as changes and fixes can go out in the next deployment within 48 minutes.

Number and frequency of software releases
Volume of defects
Time/cost per release
MTTR (Mean Time to Recover)
MTTC (Mean Time to Change)
Number and frequency of outages / performance issues
Revenue/profit impact of outages / performance issues
Number and cost of resources

  

Scrum / Agile Resources

A few of my favorite Scrum and Agile related videos…
Do have favorites not in my lists?  Please leave a link in the comments.

Role of the Product Owner

Planning Poker

The Daily Scrum

Intro to Agile

Agile Project Ownership in a Nutshell

S**t Bad Scrum Masters say

Distractions – What the internet is doing to our brains

The Pomodoro Technique

Pair Programming

TDD

QUnit

Hitler Scrum

I want to run an Agile Project