Category: Scrum

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.



Iterative thinking

768px-Screwtop_spiralTHE “WATERFALL” VS “AGILE” BATTLE SEEMS TO BE OVER BY NOW AND AGILE HAS EMERGED AS THE WINNER.  Still the current software development landscape is far from the order. It is filled with many tools, processes, frameworks, methods, methodologies, best practices, procedures (Be my guest …)

This drives many software development teams in to confusion. Outcome of this confusion is that teams have been following processes, methods, etc. just as a recipe. It can be scrum, XP, Lean Start up or even SAFe but you will see many teams use them without understanding the underlying thinking. Probably this is one reason why the (almost) movement “Be agile” had to be born.

It is obvious that teams should not use “Agile recipes“. There is no better reason than the first value of Agile manifesto to show why any team should not use a recipe . The first value states ” INDIVIDUALS & INTERACTIONS over processes and tools”. What has most value is the team itself and the interactions around it, not the use to tools. Teams should understand the basic underlying thinking of these Agile methods in order to be successful.

So the first question is what is the underlying thinking and the second question is whether is there any similarity of this underlying thinking? There is very simple answer to both the questions. All these Agile methods are based on a simple concept of  “Iterative thinking” (at least what it should be). Applying any Agile method just as a tool will not guarantee the success of the project but if one can find the success if he/she understands and applies iterative thinking. In my view, there is no need to use ANY tool or method if one can master and use iterative thinking in a project.

So the big question is what is “Iterative thinking”?

Iterative delivery


Iterative thinking is connected to all the areas of software development. Iterative planning, Iterative design, Iterative development, etc. are examples. Iterative thinking can be simplified in to “it is all about slicing the customer need and deliver the solution in a progressive piece meal manner“. One important factor here is that each delivery should ensure that it is build on top of previous delivery and the future deliveries can be build on top of it.

The outcome of the “Iterative thinking” is the “Iterative delivery” and it is an extremely important concept when it comes to complex domains, scopes, etc for the success. When it comes simple software problems, the iterative thinking becomes less visible and just using a recipe can lead to success.

The “Iterative thinking” can be illustrated in an example. Let’s take typical user management feature:


  • The first iterative delivery can be a simple screen where users can be added to the system and the added users are listed in a crud list. There are no validations for the user creation form. Not much thought given for the design of the user management feature. The main objective is to get the initial thinking in sync between the development team and the problem owners. This delivery can be called as “User management Spike”.
  • The next delivery can be “Basic user management” where more features are beefed up on top the the user management spike. It can be that user creation form has more fields and validations are added, passwords are encrypted, etc. Also the basic design of the the user management has emerged.
  • This can be extended to further iterations till the problem owner is satisfied with the given solution.

(This should not be confused with incremental delivery. See this


When it comes to complex software problems (such as automated vehicle guidance systems, etc.) there will be many more iterations than a simple user management feature.

  • The first iterations can be that nobody touches the code and it is all about presenting (by PPT) team’s understanding on the requirements.
  • The next iterations can be further strengthen on design aspects of the system (if team feels a certain up-front design is required).
  • These iterations can be further worked on through providing basic integration tests.
  • This can continue from the first delivery to final user acceptance.

The magic behind the “Iterative thinking/delivery is rapid & constructive feedback. When a team follows the iterative delivery, the feedback would be specific (such as saying “I don’t need the “middle name” field here, add a new field called “Date of birth”, move the “address” to the bottom, show the last login date/time, etc.) This specific feedback would speed up the team thus resulting rapid value delivery which fits to the purpose.

So in conclusion what can be noted is that the important fact in Agile software development is not to use the tools, processes, frameworks, methods, methodologies, best practices, procedures, etc. as recipes but to understand the concept of Iterative thinking. The simple use of Iterative thinking can lead the successful project delivery even ignoring all the norms and prescribed methodologies such as Scrum.


What is waterfall?


Recently I have been involved in a discussion what is waterfall (of course in software development perspective).

The very first thing comes to the mind is that waterfall software development is a phased approach (over iterative Agile). You have got defined phases and boundaries to cross like “Requirement phase, Design phase, etc.”

If you stop for a moment and look in detail, you will realize that this is more of a description of the “Execution model”. Or how the Waterfall model is executed. But there is much more deeper conceptual definition if you look at from a business perspective.

When you look at software engineering from the problem vs solution concept, you can see it. Software is a solution for a business problem. And software engineering is all about articulating the solution.


So this is how the Waterfall approaches;

  • You have the “Business problem” and
  • You have a layer to “Specify the problem” (requirement),
  • Another layer to “Specify the solution” (architecture and design),
  • Another layer to “Develop the solution” (development),
  • Another layer to “Confirm the solution” (testing)
  • Final layer to “Apply the solution” to the problem (Deployment).

Through this you can transform the horizontal phases of waterfall to vertical layers and by doing so you can see how the waterfall development is really structured.

I don’t need to mention the waste and the confusion this causes when you have so many layers between the Problem and the Solution.

But Agile software development provides a much more compact approach which is more effective than Waterfall. In Agile, you just have two layers representing the Problem and the Solution. Problem is represented by Product owners (if you consider Scrum) and Solution is represented by Development team. By reducing the unwanted layers in the middle, Agile has reduced the waste and the confusion.

But as a note this doesn’t mean that you can avoid the needed steps like design, testing, deployment, etc. It is just that all are done within one layer


Scrum Guide 2013

Ken Schwaber's Blog: Telling It Like It Is

Jeff and I have been working on the next revisions to the Scrum Guide. We will be presenting a webinar about it within a month or so.

We first presented and published Scrum in 1995 at an OOPSLA conference in Tampa, Florida. Almost twenty years have passed. Agile and Scrum have succeeded far beyond our expectations. Actually, we never had expectations beyond using Scrum for ourselves, so anything more was easy.

Between 1995 and the publication of the Agile Manifesto in 2001, Mike Beedle, Martine Devos, Mike Cohn, Deborah Stenner, Tonya Horton, Will Smith, and Alan Buffington all moved Scrum forward, using it and helping us refine it.

After 2001, I started holding Scrum training classes, first called Scrum, then Scrum Master, then Certified Scrum Master classes. Some of the people in those classes had epiphanies. They wanted to help spread Scrum through training and consulting. Some of them (and…

View original post 140 more words

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.

Velocity vs Agility

I just wanted to compile few interesting posts which is going around last couple of years in the Agile Circle. It is about using velocity as a productivity measure. Here are the few references

In summary what all of them mention is that it is wrong to use the velocity as a productivity measure to reward or punish the development teams. If the organizations use “Velocity” this way, the problems would be

  1. Lose focus on customer value and creativity
  2. High focus on estimates which may be a waste
  3. Teams would inflate the story point estimates
  4. Etc.

Rather velocity should be used as a measure for capacity planning. For example size of the backlog divided by current or average velocity, can provide a fair idea of how many sprints it would take to deliver the product backlog.