Story Points Estimation

When planning an agile project creating User Stories and estimating their complexity is an important step to provide your customer and delivery team with a clear understanding of the solution being developed.  Estimating the complexity of a User Story is something typically done by a Product Owner after or during a meeting with a customer then verified and approved by the delivery team during release and sprint planning.  Make no mistake that this is a consensus not a majority rules estimation process.  While the project owner gets first stab at story point estimation it is the delivery team that will be responsible for doing the actual implementation. The delivery team should never commit to adding a story to a sprint without first having a conversation about the delivery team tasks required to bring the story to the teams stated definition of done.

Since we are estimating relative levels of complexity and not actual hours a modified Fibonacci sequence can be used for estimations of User Stories received by the development team.  This will help keep the team from getting bogged down looking for exact estimates and allow them to “round up” to the next level of complexity.

0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100

Complexity vs Hourly Estimates
Humans are not very good and estimating actual time for complex activities.  But we happen to be very good at estimating relative complexity, this will be about as about as hard to do as that was.  So when estimating at a high level such as story points it is best to keep those estimates at the relative story point level and save the more precise detailed estimates to the delivery team tasks to be captured during release and sprint planning.  Also whenever possible it is best to keep User Stories to a size that will fit within a single sprint, even better to keep them down to 1-3 day sized chunks.

Ultimately Delivery team tasks will be nested beneath the User Stories at a more granular level so we can save time estimates for these smaller work items.  The sweet spot for tasks nested beneath User Stories 2 to 4 hour chunks.  After 6-10 sprints and sprint planning meetings your teams story point estimations should be pretty accurate.

Since the teams capacity describes the amount of story points that the team can finish in a sprint and a sprint is a time boxed event if we accurately estimate the number of story points we can finish in a sprint we can extrapolate the number of hours required to complete the committed story points.

A great way to start the conversation about task estimates is to play Planning Poker.  Here is a great video to get your started:

User Story Slicing
If our User Stories are too large to fit into a single sprint it may be an Epic or Feature masquerading as a User Story, in this case it is best to break this large complex User Story down into smaller chunks to make it easier to understand.  We call this process slicing or sizing of the User Story.  If we think of the User Story as a slice of double chocolate layered cake (the flavor was irrelevant but call it a craving) then we can think of our slicing efforts as a slice of cake from top to bottom and not simply peeling off the top layer (otherwise you miss out on the frosting between the layers).

Slicing the cake vertically means we follow our business process from the User Interface layer all the way through to any data access components that might be involved, in other words if we have a log in user story we can actually log in because the UI, data layer and database required by the story are all in place.

Small Increments
Let’s break things down into smaller components so that you can understand.  The larger the size of the user story the more moving parts it has, the larger the margin for error.  Also if the user story is too large to fit in a sprint it will affect the team’s apparent capacity and velocity as the burndown chart will not move until the story is marked as complete.  A large user will have many delivery team tasks nested beneath it each of these tasks will have its own time estimates and since the sweet spot for these tasks is 2 hours a large user story could potentially have tens of tasks associated with it.

Story as a container for work items
The User Story is a high-level nontechnical customer requirement and is meant to ease communication between the customer, product owner and delivery team.  As such the user story is not the place for technical detail, this is the realm of the delivery team task (formerly known as developer tasks).  The story point complexity rating has a direct impact on the number and size of delivery team tasks to be expected for each user story.  As a general rule it is best to keep tasks to small workable chunks created and assigned in 2 hour increments.  Two-hour delivery team tasks make estimation far more precise by reducing the margin of hour to minutes instead of hours or days.  During sprint planning we should strive to identify about 2/3rd of the required technical delivery team task as the effort and time required to identity 100% of technical delivery tasks.  We should spend on average 2-4 hours in sprint planning for each week of the sprint.
The more complex the User Story the larger the delivery team tasks will be.  The larger the delivery team task the less accurate the task time estimates will be.  Put simply the more we reduce the amount and size of work in progress the more accurate our time and complexity estimates will be.  See our post on Slicing User Stories for more detail on how to size or slice large and complex User Stories.


Scrum Ceremonies Dont just hit the bullet points! (Rant)

Are your Daily Standups and Sprint Retrospectives taking too long?
Do important stakeholders frequently skip your meetings?
Do team members question the value of your Standups and Retros?

It may be time to reevaluate the priorities of your daily standup and retrospectives.

Don’t just hit the bullet points!
A retrospective is not just about what you did yesterday and what you are going to do tomorrow and what impediments you have encountered.  I’m sure that any agile development guide, website or blog post you read will tell you that a daily standup or sprint retrospective is all about discovering:
What we did well?
What we didn’t do well?
What we’re going to do better next time?
Are there any impediments?

These are the standard bullet points to hit during your daily stand up and sprint retrospective.  But if all you do is hit these bullet points you’re missing the point of a daily standup and sprint retrospective.  The goal of these scrum ceremonies is continuous feedback and continuous improvement therefore your feedback is only valuable if:
What you did or discovered yesterday represents a learning experience for the team
You completed a task that was blocking other work
Learned a more efficient way to complete a task
Discovered a previously unknown dependency
Documented / Performed a previously unstated delivery team task

These items will be of interest to the team.  But simply stating that you are working on the same thing your worked on yesterday and the same thing you will be working on tomorrow is not useful in the standup or sprint retrospective as this information should be available on the team portal and project timeline.  It is also important to avoid “solutioning” during? these ceremonies as the act of creating a solution for a problem facing certain members of the delivery team excludes other team members and stakeholders.  This kind of information with narrow relevance will eventually cause team members and stakeholders to avoid the meeting.  Repetitive, minimally useful information provided as part of the software delivery cycle will quickly be categorized as noise and summarily ignored.  Take heed and ensure that all information you provide and request during these scrum ceremonies is timely and relevant.

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

Cross Site Scripting (SQL Injection) Attack

A SQL Injection Attack is one of the many security issues that must be address when designing and developing applications that access a database.  The injection vulnerability is potentially present on pages or forms where the user must enter a value to be submitted to the server. If the user input is not properly validated and the database doesn’t protect itself then SQLiA can occur. I have posted the source for the sample application on the portal. To download the SQL Injection Attack Sample Web Site and SQL Script click here: VB.Net Version or C# Version To run this demo code you will need Visual Studio 2008 or higher and SQL Server 2000 or higher installed.  See the video below for an overview of the sample app.

The file consists of a T-SQL Script file named CustomerOrdersDB_SQLInjection.sql used to create the database, tables (including sample data) and stored procedures (Stored procedures were created using CRUD Script) and a Visual Studio 2008 project called Demo.sln. The Visual Studio Solution contains 2 pages: SQLInjection.aspx and SQLInjectionFixed.aspx that as the names imply illustrate a page that is vulnerable to SQL Injection and one that is not (not all possible SQL injection attacks are prevented but most).
Test it out here:

To test the search feature that’s vulnerable to SQL Injection:
Open the Solution (Demo.sln)
Select SQLInjection.aspx in the Solution Explorer
Press Ctrl + F5 or Select Start without Debugging from the Debug menu
Type Antoine into the search box
Press the Search button
Note: You will notice that the results displayed on the page are filtered to show only Antoine Victor.
Try a couple more searches then continue
Copy the injection statement from the bottom of the page
Paste into the search box
Press the Search button

Note: You will see a list of all of the tables defined in the current database and all columns defined in those tables.
Think credit card table, employee table with Social Security Numbers.
Armed with this information a hacker could use the same SQL Injection vulnerability in this page to then request columns and rows from the credit card or employees table.
Fortunately there is a relatively easy fix for this. The fix is a 2-part process, first we validate the user input before sending it to the server and removed any special characters or malicious code, and second we make all calls to the database through stored procedures (created automatically using CRUD Script or the SSMS Toolkit)
To see the page with the Injection issue resolved in the current browser window navigate to SQLInjectionFixed.aspx and follow the previous steps.
“This” SQL Injection issue is now resolved.
For a list of other common injection attacks to test with this demo see: SQL Injection Cheat Sheet.
For details on storing the connection string in the config file and stored procedure calls see the videos below.

Refactor the code so that it is easier to update and maintain:

Add stored procedures to prevent SQL Injection:

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