Skip to content
November 6, 2013 / Raluca-Nicoleta Bejan

How Scrum can help me to save money on the long term ?

It was almost midnight when I heard my phone ringing. For my clients from the other part of the Globe it was middle of the day. And not a particular good one. Nothing was working for them because of a bug. What bug? Well, a bug which appeared when they tried to use the application with their new file format. Apparently this blocked their entire system.

Damn (!!!) (sigh), not much to do at this hour, I thought, let’s wait for the morning to come to have the chance to talk with the development team, hoping that we will still meet our SLAs.

Morning came and I called the technical guys. What ?? Only Alex can solve the problem and he is on holiday?? And he is coming back in two weeks??…

As you can imagine, there was no happy end. And the company had to pay a lot of money for not respecting our SLAs.

Does the story above sound familiar to you?

How many times did you find yourself in the position to realize that after, let’s say, five or ten years, the cost of ownership for some software system was unexpectedly higher than the purchase price?

How many times you did not realize that because of the time (and therefore money) spent on fixing old bugs you did not have time for developing new features?

How many times you did not think of adding up the the hidden costs (i.e. bugs, maintenance) to the initial calculations and in the end you realized that your company spent an incredible amount of money for owning some piece of software?

Unfortunately, I am sure that many of you know what I am talking about.

In this post we will discuss how to measure the cost of owning a software application and how to decrease this cost as much as possible.


For measuring how much a software application costs, instead of considering only the purchase price of an object, the complete cost from purchase to disposal have to be summed up. This calculation is called Total Cost of Ownership, abbreviated TCO, and is designed to help in financial decisions by giving a picture of the profitability over time.

For many software products, TCO analysis finds a significantly large difference between the purchase price and total long term cost, especially when calculated across a long ownership period.


Now, how Scrum can help to reduce TCO? I will explain why the costs to enhance, maintaining and support an existing software will be more reasonable when working with Scrum and why the risk to end up with a buggy product code – translated in higher costs for Support team (and possible Sales team), less time or more money to develop new features and high risk not to be able to keep your clients – is minimal.

Less time – and therefore money – is spent on understanding the existing code :

Make sure that refactoring of the existing code is included in the Definition of Done. A clean code, without duplicates, will be easier to read and understand. If the design and code are not constantly refactored, will be more and more difficult to enhance and sustain your application.

You will spend less money on adapting the existing code :

Because of eliminating waste, only the important features, with the highest chances to be used, are implemented. Therefore, when adding another new functionality, you will spend the minimum amount of time thinking which will be the impact of the new feature over the entire application. Also, if the new functionality needs changes in the existing code, these changes will be kept at minimum, because, again, only the important features are implemented and there is no need to spend time and money on modifying and adjusting unused code.

Decrease TCO by having automated tests :

Make sure you include automated testing in the Definition of Done. Having a battery of automated tests running daily, will be visible quickly if any of the new features affected the old ones. When something is changed, you can check if the product continues to work. If you do not have a complete set of automated tests, you will not know when the system will collapse and what exactly was broken.

Save money by focusing on quality :

If the bugs are not fixed, the costs of maintenance and support will increase and therefore the value of your software application will decrease. I am sure you prefer to have the Sales Team promoting the new features instead of trying desperately to explain to the furious clients why some problem happened. Same for the Service Desk Team, you would prefer to have them involved in Beta campaigns for the new products instead of finding workarounds for the old bugs.

Other important thing, the pace on which the work is performed should not have a negative impact on the quality. A productive Development Team works at a sustainable pace of 8 hours per day. From my previous experience if the team members have to work more than 8 hours per day, the quality and the new ideas will be somewhere under the sea level.

According to Ken Schwaber, an organization that went from 8 hour days to 12 hour days had an increase of defects of 60%. The cost to re-mediate the defects in a 9 month product release more than offset the additional “productivity” of the additional 4 hours per day.

Now, in the end, given the current software project you are working on, can you tell:

    • Which costs are most important for your project in influencing overall TCO results?
    • What can you do starting from NOW to minimize costs?
July 5, 2013 / Raluca-Nicoleta Bejan

Why is the Sprint Goal so important ?

I understood early in my work how important is for a team to be focused. The problem is that you can’t keep a team focused only by giving them a long list of user stories to work on. It will be pretty hard to remember all of them after a day or two. Would be way better, in order to keep the focus, to make them understand the idea behind their work.

This is when the Sprint Goal comes into discussion.

The definition from the Scrum Guide says that: The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment.

The Sprint Goal is a short piece of text (one or two sentences) that expresses what the team should aim to accomplish in the current Sprint. It is written collaboratively by the team and the Product Owner. Sample Sprint Goals are “Add search capability to the application”, or “Provide a way to send notifications via e-mail”.

In this post I will explain why the Sprint Goal is such a powerful practice.


Helps to commit to something valuable for the client

Sometimes happened to me to ask a Scrum Team I worked with about their Sprint Goal and to receive answers like: “deliver this number of story points” or “deliver this list of completed user stories”. This does not say basically anything – sounds more or less like working to earn some money without not having any idea about what to do with them afterwards.

I am not against the metrics, on contrary, I see their role, but if the numbers are the most important thing, then you will likely get exactly this – completing some number of stories or story points. In this case, most probably the less risky and easier stories will be selected by the team, and they may be of lower value than the other stories you have in the Product Backlog. At the Sprint Review the clients will not be interested at all in how many story points were done or in the number of user stories completed. Their expectancies will be to see meaningful working software.

During the Sprint, the Development Team creates an increment of specific potentially releasable functionality, described by the Sprint Goal. This increment integrates into the big project vision. The collection of all the Sprint Goals should equal the overall project goal.


Gives the Development Team flexibility regarding the functionality implemented

Having a clear and documented Sprint Goal gives the team some flexibility room when building out new functionality, as it is also stated in the Scrum Guide.

It may happen that, at some point in the Sprint, the Development Team to discover a better way to obtain the Sprint Goal. If this makes some of the stories obsolete, obviously that stories will not be implemented anymore. The team will get credit for finding a smarter and better solution.


Helps the team to have a common understanding about the work they share

Without a shared Sprint Goal, everybody in the team will have their own version about what is to be done in the Sprint. Therefore, they will build software based on what they think is the Sprint Goal.

Same applies for the stakeholders, they will come to inspect at the Sprint Review what they think the Sprint Goal is. This, almost always results in having incomplete stories.

Shared Sprint Goals create focus towards the same thing and facilitate teamwork.


Makes prioritization easier

Having a Sprint Goal definitely helps with the prioritization. Once the Sprint Goal is clear, the Scrum Team has to identify all the stories from Product Backlog which will contribute to it. The stories are ordered after this by the Product Owner.


Facilitates inspection

If the Sprint Goal exists, this will help to invite the right stakeholders to the Sprint Review meeting. For instance, if the goal is to evaluate the new web interface, the team will need to get feedback from the user’s representatives. If the Sprint Goal would be to add a new reporting capability, then the technical support team and \ or Product Owner would be interested to inspect this.


Helps to communicate better with the stakeholders

Suppose that you meet any of the stakeholders (or the CEO 🙂 ) accidentally on the stairway and he or she asks you what are you up to in the current Sprint. It is way easier to use the Sprint Goal instead of telling the user stories list.


Helps integrating feedback

Having the Sprint Goal connected to the big project vision, as I described in the first paragraph, will help the Scrum Team and the stakeholders to see the link between the current work and the final product. This will make easier to see how the current work is related to the work expected in the next few sprints. Will be useful when reviewing the upcoming user stories during backlog Grooming Sessions.


Final thoughts

Yogi Berra said that “If you don’t know where you are going, you might wind up someplace else”. Making sure you have a Sprint Goal will increase your chances to head towards a successful product.

May 22, 2013 / Raluca-Nicoleta Bejan

The long way to ‘Done’

photo credit: Marty.FM via photopin cc

The long term success of any software project critically relies on delivering a done increment.

But what ‘done’ means? For me, ‘done’ simply means that there is nothing left to do – at least nothing we know of. As it is stated in the definition from Scrum Guide, it concerns more the quality of a product, rather than its functionality.

However, I noticed that, in a lot of practical situations, there is a substantial gap between theory and reality, and delivering a ‘done’ increment still remains fuzzy for the teams. In order to make the gap smaller, I noticed that there are some questions, asked over and over in my Scrum projects, which need to be clarified.


Why is so important to have a Definition of Done?

During the Sprint, every single member of the Scrum Team is responsible to follow, and adhere to the definition of ‘Done’, in order to implement the work added in the Sprint Backlog. Without a Definition of Done, the Development Team would not know what to ship, and even worse, would not know if what they want to ship is what the client wants. Also, the progress during the sprint has to be visible for the Product Owner and the clients. The content of Definition of Done has to be clear for everybody. Transparency means not only visible, but, more important, understandable.

In the Sprint Planning meeting, the Scrum Team develops or confirms the Definition of Done. This is used further by Development Team to know how much work to fit in a given Sprint. Without it, it easy to over-commit – not having defined clearly what to do leads to the illusion that the team can do more than the real capacity.

For the Review Meeting, it is essential to have the Definition of Done clear for the stakeholders and for the Product Owner, otherwise they may not understand what are they inspecting and what to expect from this meeting. The inspection of the working Increment and the Definition of Done at the Sprint Review, and the related collaboration of the Scrum Team with the stakeholders, will provide the Development Team with important information to sustain, evolve and grow the Definition of Done.

In Retrospective Meeting, the Definition of Done is revised and it is possible to be changed, if, for instance, the Scrum Team decides to tighten up on the quality goals.

Although is not an official artifact, each team should have ‘Done’ defined. It helps to have transparency over the work performed by the Scrum Team, also helps the Scrum Team to work more coherent and consistent. Certainly, by having it, will improve a lot the quality of the products.


Who is responsible for defining the Definition of Done?

Both Development Team and Product Owner have to define together what ‘Done’ means. The Definition of Done can be seen as an agreement between them. In the end, the Definition of Done represents the Scrum Team’s capability of delivering potentially shippable increments but also reflects it’s maturity level.


What does the Definition of Done contains?

It is practically impossible to build a Definition of Done that suits in any situation. What can be done, is to create a list to be used as a starting point. For a particular project, different scenarios should be considered in addition to be sure that all the checkpoints are met.

I am sharing the list I am usually using as a base and adapting afterwards, function of project:

Functional Organizational Expectations and Compliance Testing Coding Build and Architectural Changes Documentation
Implement functional expectations from the Product Owner. Do what needs to be done to obtain compliance to any program or standard. Do acceptance testing and integration testing. Write the code and check-in in source control. Do build changes according to the updated deployment instructions. Prepare release notes / release information
Implement the updates needed for existing features, to include newly implemented features. Synchronize with the appropriate teams if something will change regarding integration. Do regression testing. Do continuous design and constant refactoring. Do architectural changes (i.e. a new database needs be added or on contrary, more databases need to be removed). Write test case scenarios
Identify Inactive/ unimplemented features hidden or greyed out (not executable). Do localizations. Do performance/ load/ stability testing. Repair any problems detected by the code review tools (i.e. Sonar) and write unit tests. Verify upgrade while keeping all user data intact. Document the new feature.
Identify data and relevant test cases for the Review meeting. Do security testing. Code review completed (or pair programmed). Include stubs and simulators for non-available systems. Document the deployment instructions.
Identify and implement the non-functional requirements. Add automated test(s). Include new automated tests into the battery of tests running on continuous integration server. Integrate the code with the work of other teams if the case. Simulate deployment of the release build.

Is Definition of Done formalized somehow in the team?

Just make a list and make it visible for everybody. Bring it in the Planning Meeting, Review and Retrospective Meetings, and post it on the wall in the office.

At the Product Backlog level, if you are using an electronic tool, personally, I recommend to work by having a generic template for an user story with all the sub-tasks representing the list of activities for producing the potential shippable increment. When a new user story needs to be created, start with the template, add the description and the acceptance criteria, delete the unwanted sub-tasks if the case, and discuss and detail the remaining ones. Do not forget that you can add as many sub-tasks as you need for the functional developing and testing in order reach the desired granularity level (as a reference, I recommend that a sub-task should not take more than two days).

If for some reason the idea with the template does not suit you, just work with a list.


What happens with the undone work?

The undone work is called technical debt. Some examples for technical debt are code duplication, untested features, poor design, etc. Technical debt accumulates in a non-linear manner, like a rolling snowball that gets bigger and bigger as it rolls.

This is why I stated in the first phrase of this post that “long term success of any software project critically relies on delivering a done increment”. The bigger the technical debt, the less time remains for developing new features. The undone work has to be paid when discovered, otherwise the problems (i.e. uncertainty in plan, high risk, extra cost, etc) will become bigger and bigger and impossible to be repaired at some point. In many organizations, Scrum is scaled to use more Scrum Teams to build a software product. In this situation, the technical debt becomes greatly amplified.

May 22, 2013 / Raluca-Nicoleta Bejan

Terms explained: What ‘Velocity’ means in Scrum ?
photo credit: wwarby via photopin cc


Velocity is a measure for the Development Team’s ability to turn requirements into shippable functionality, across a fixed period of time (i.e. sprint). The measure is for the amount of produced functionality, not for the value produced. You can also call it ‘Productivity’ or ‘Capacity’. Do not think this is very complicated – it is really easy to understand and use and its value comes from its simplicity.


How do I calculate velocity?

For calculating the velocity, you just have to add up the story points for all the ‘done’ items in a sprint.

Because the story points are estimates for the effort required to implement backlog’s items, a team’s velocity is not useful in itself. Instead, it becomes a very useful metric over time as teams complete more than one sprint (from my experience, more than 4-5 sprints). As the Development Team is building up, if you will have the same team members and the length of the sprint will remain the same, then its velocity will stabilize within a range and become predictable.

Make sure that the Development Team is always estimating using the same estimating criteria. Otherwise, it will be impossible to compare the velocities for different sprints.


Who will use the velocity and when?

In Retrospective Meetings, Development Team can use velocity to measure improvements or the opposite, the problems, regarding how much delivers. If the velocity value increases, this is the result of better teamwork, better development tools and practices and increased experience. On the other side, a drop in the value of velocity can make problems more visible i.e. more training is needed, more people are needed in the team or the product owner has to be more involved.

Velocity from previous sprints can be used as a guide in the Planning Meeting by the Development Team. For example, with a stabilized velocity of ‘x’, they will consider taking that total number of story points into a Sprint. But, after discussing each story and split them into tasks the Development Team can take a number of ‘x – 1’, ‘x – 2’, etc. or the opposite, more than ‘x’ story points. Velocity is used just for guidance.


Are there tools using velocity?

One tool widely used is velocity graph. It shows the amount of effort that your team has reported as complete for each sprint. You can draw the chart by yourself or use tools like Visual Studio. The source of the data is your product backlog. The horizontal axis represents sprints, and the vertical axis measures the backlog effort that your team has reported as complete (the effort is shown in the units used by your team, i.e. story points or hours). The graph also displays a horizontal line that represents the average velocity across all the sprints.

April 21, 2013 / Raluca-Nicoleta Bejan

Don’t forget about non functional requirements !

photo credit: OpenEye via photopin cc


I’ve seen lots of smart solutions that turned out to be unusable when you actually considered how to use them in the real world, by real people. One of the main causes of this is ignoring the system’s non-functional requirements.

Let’s take a few examples to illustrate my affirmation above:

Let’s say you are preparing to see a great movie, one you expected to see for a long time. The movie promises to have a great story and an excellent distribution. But from the beginning to the end you are annoyed by the quality of the sound and the quality of the 3D effects. While the story is amazingly good, the whole experience is not so great and this is due to the non-functional problems.

Another example would be about an online web exam. If the response of the site is slow and and if it takes too long to until the registration is confirmed, users are unlikely to have a good experience.


How do I know the nonfunctional requirements checklist ?

In order to have a list as complete as possible (can be updated anytime afterwards), the best thing to do is to involve both Development Team and the users.

The Development Team can help a lot. They will know, for instance, if a new version of operating system will be released in the near future and what new particularities have to be taken into account. Also, you can use their experience on a similar product. Apart from Development Team, would be a good idea to ask the members of the service desk and operations teams about the information they have, from their experience with the users, about needed availability, accepted performance level or their expectations regarding security.

Also, for the users, conduct interviews and workshops, and organize user tests for early product increments or even on prototypes. These tests allow you to discover new questions and possibly to understand more about their expectancies about performance, availability and so on.


Can I use as a start point a minimal existing nonfunctional requirements checklist?

From my experience as a Scrum Master, there is a common list of non-functional requirements that I saw the need for in most of the projects I worked in. Now, depending of the developed software, you can use an extended version or a subset of this list.

    Availability is the amount of time that an application is operational and available for use.
    Some systems have to be available all the time for all the users and others are designed with expected downtime for maintenance activities or upgrades.

    Practical examples: An antivirus application which has to be up & running all the time and there are many online applications which have maintenance breaks weekly or even daily.

    Performance of an application concerns the speed of operation of a system. Depending on the application developed, you may need to analyze the following aspects:

      • Response time or how quickly the system reacts to a user input.
      • Rate of processing work or how much the system can accomplish within a specified amount of time.
      • Utilization of computing resource(s).

    Practical examples:
    • Response time – for a search engine application, the amount of time to perform a search.
    • Rate of processing work – for an antivirus, the number of scanned files per minute.
    • Utilization of computing resource – the processor rate needed by a computational application.

    Portability specifies how easily a software application can be moved between and used on different computer or mobile operating systems.
    Again, depending on the developed software, you may need to analyze the following:

      • Possibility to run can the code exactly in the same way on all platforms.
      • Check if data files are transferable and if the data formats are supported on all platforms.
      • Asses if the application will have the same look and feel across platforms with the same interface, commands and keystrokes.

    Practical example: For some of the computer games for Windows there are versions for mobile phones operating systems.

    Integrity \ Security
    Security requirements define the processes and mechanisms by which applications are protected from unintended or unauthorized access or destruction. This also includes protection from unplanned events and natural disasters.

    Practical example: The requirements for a strong password.

    Scalability specifies the ways in which the system may be expected to scale up: i.e. by increasing hardware capacity, adding machines, etc.

    Practical examples: An online application for backup and restore content have to be designed having in mind that at some point more space may be needed. A search engine application or an online game application, with a potential of millions of users have to be designed with the possibility to scale the processing resources.

    Usability measures how easy it is to use a product – this is different from how likeable a product is or about the ability of the product to perform certain tasks.

    Maintainable software allows you to quickly and easily: fix a bug, add new features, improve usability, increase performance and make changes to support new environments.

    Reliability specifies the capability of the software to function in a specified environment for a given amount of time.

    Practical measure for reliability: Software reliability is measured in terms of mean time between failures.

    Robustness is the capacity to tolerate problems gracefully, without failure. The problems include unanticipated events, invalid inputs, corrupted data, improper usage, unavailable resources, etc.Joking a bit, we can put it as a measure of how hard is to break someone’s code :).

    Practical examples: A software application should not terminate in case of invalid API-requests; those have to be rejected.


How do I make sure that functional requirements are not overlooked?

Capture the requirements precisely, the purpose of analyzing the list above is to produce non functional requirements that can be measured and tested. As part of continuous integration, develop and maintain automated test to validate the non functional requirements.

I believe that the most important thing is (I am really stressing this) to take care of these requirements as soon as possible, sometimes it is impossible or very expensive to implement them after the software is already developed.