Category: User Story

Managing queue length

Queue-2012-12-11Optimizing the software engineering is no easy task. The intangibility of software assets in combination that most of the engineering happens at the human brain makes it difficult to see the whole picture. Optimization requires visibility. This is where the lean manufacturing provides a good foundation to optimize and improve the software engineering as a whole. The pioneers like Mary Poppendieck & many others have already paved the way.

Taking a leaf out of the lean engineering book, one of the important concepts that comes along with SAFe is “Managing the queue length”. The longer the queue, higher the waiting. In lean manufacturing, waiting is  one of the seven wastes. Therefore managing queue length is important.

What is a queue in software development?

At the first glance, we don’t see any queues in software. But if you make a deeper look in to the definition of the queue, you will see many long queues. According to merriam-webster queue is a “line of people who are waiting for something”.

This can be easily mapped to “List of features which are waiting to be developed”. Going further, product backlog is the list which contains the features (user stories). Does this means the product backlog is a queue?

Is the product backlog a queue?

The product backlog interestingly is not a queue. The justification lies on the fact that queues cannot be easily re-arranged and typically works on FIFO basis. If you try to change the queue at the bus or train station, you will not have happy results.

In this meaning, you can change the order (prioritization) of the backlog so it is not a queue.

Waterfall is primarily about long & costly queues

Everything is planned and scheduled at the beginning in a waterfall project. This is essentially a long queue & it defines who will work on what even at the last week. The problem with the queues are multi-fold. It creates long waiting time for new features. The most dangerous fact is changing the queue (schedule in this case) is very costly.

For example if there going to be a change to the requirement, the whole schedule needs to be adjusted. If there are external dependencies such as delivering a component to another team, etc. then it requires lot of effort to change the queue (schedule).

This is the main reason why changes are primarily considered bad in waterfall projects, no matter what benefits they brings to the business. There are lengthy & costly procedures to pass a change in to the development.

Managing queue length

Any experienced Agile practitioner would tell you that they only plan next two iterations. This is essentially keeping the queue length short. Only the current sprint is committed (SAFe even reduces this commitment by introducing a concept called stretch goals) and it is only the queue we have in agile software development in a way.

All the other stories in the backlog are not planned & kept untouched. This comes from the fourth value of the agile manifesto “Responding to change over following a plan” as well as from the second principle of the manifesto “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Why we should have shorter queues?

Benefits of the shorter queues are many.

  1. The main benefit is that it facilitate the agility by facilitating changes even late in to development.Also changing is less costly.
  2. Secondly it makes the waiting time predictable. If there is an urgent change to be introduced, everybody knows it is maximum of one iteration which they have wait. 
  3. Ultimately it supports the business by allowing early realization of business value by reducing the waiting time


In software development, queues are the stories or features scheduled to be taken in to development.

In conclusion, the queues are bad due to cost of change is significant but change is essential. Agile software development by design limits the queue length and therefore supporting businesses to realize benefits quickly.

The takeaway is to limit the queue size by only planning current sprint and next sprint.



Splitting user stories

1353683732_2I had a situation where I need to find out ways to split the user stories. (This was after I instructed the team to write high-level user stories (whew)).  This was due to the complain from developers that user story is too big to estimate.

Then it was time to go back to theory. Where to look? My first preference to look in to Agile Estimation and Planning from Mike Cohn as usual and I was not disappointed there.  I found all what I need. This note is re-write the points in that book. But this is to challenge myself on an example to apply the knowledge I gained from the book.


So let us take this mock up from as an example. We have got single user story saying

As the sales manager I want the following shopping cart So that my customers can order product online.”


You can decide how successful I am on this.

Splitting on data boundaries

This seems to be the very natural out of all the suggestions. I was able to divide the epic based on Item details, discount, order summary, addresses, shipping method and payment methods. These are some of the user stories that I came up. Not the whole lot.

  • As the sales manager I want the ordered items to be shown in the shopping cart So that my online customers can see what they have ordered now
  • As the sales manager I want my online customers to see that discount details in the shopping cart it self So that can be happy about discounts they receive
  • As the sales manager I want to order amount summary in the shopping cart So that my online customers knows how much they have to pay in total

Splitting on operational boundaries

This approach is also seems to be very useful in splitting our example user story. Some user stories I came up,

  • As the sales manager I want the ordered items to be shown in the shopping cart So that my online customers can see what they have ordered now (note this user story seems to be common for both the approaches )
  • As the orderer I want to enter discount codes for my order So that I get a discounted price
  • As the orderer I want to select different billing and shipping addresses So that I can get the goods to my parents home instead my home
  • As the orderer I want to have many different shipping options So that I can get special discounts/expiditated shipping for my order
  • As the orderer I want to select different payment methods So that I can be flexible on my cash flow

Splitting on performance (non-functional) boundaries

I found this approach is not much relevant but this is what I came up with.

  • As the sales manager I want something working as a online shopping cart  as first cut of it So that I can give feedback
  • As the sales manager I want the shopping cart to be in line with my corporate theme So that I can go to the market with ti
  • As the sales manager I want to shopping cart to load within 1 seconds under the specified conditions So that this can be faster than my competitors shopping cart
  • As the sales manager I want the shopping cart to stand a possible denial of service attack from my competitors So that I can stand out in the competition

Splitting on priority

As described in the book, we can easily divide the epic based on priority. I assume functionality like different shipping methods, payment methods, etc. are with less priority.

  • As the sales manager I want the basic shopping cart functionality as specified So that I can test out the concept in the market
  • As the sales manager I want to provide different shipping methods later So that I can be flexible to my online customers
  • As the sales manager I want to provide different payment methods later So that I can be flexible to my online customer payments

Splitting on common activities

This was difficult to come up with the user stories but thinking a bit and reading the book again, I came up with this.

  • As the sales manager I want a basic shopping cart functionality as specified So that I can test out the concept in the market
  • As the sales manager I want to add validations to user inputs later So that I have the correct data in to the shopping cart
  • As the sales manager I want to validate whether entered credit card is a valid card So that I stop fraud
  • As the sales manager I want see a log of anonymous usage data of the shopping cart So that I can know the success of the functionality

As summary the chapter 12: splitting user stories was very useful and I really enjoyed reading it.

Why Does the Customer Write the Stories?

From Mike Cohn – User Stories Applied
The customer team, rather than the developers, writes the user stories for two primary reasons.

  1. First, each story must be written in the language of the business, not in technical jargon, so that the customer team can prioritize the stories for inclusion into iterations and releases.
  2. Second, as the primary product visionaries, the customer team is in the best position to describe the behavior of the product.