Thursday, May 24, 2018

Most Common Mistakes During the Transition to Agile (Part 2) | Supreme Agile

תוצאת תמונה עבור ‪agile transformation‬‏
When examining the last few years, we can see the extended amount of organizations that use Agile frameworks (Especially Scrum) as the preferred software development methodology. Some organizations had a massive success implementing and adopting Agile. While other organizations achieved partial success due to well-known problems that I will cover in this article.

Well, how can it be that organizations fail to adopt Agile? This is despite the fact that it is well known, there are many implementers, coaches and endless knowledge on the internet that is available for everyone. 

Well, the answer is not surprising and relatively simple. Agile is a document with a set of principles and values that are interpreted differently by different people. The direct result of this interpretation is the creation of too many ways to implement the method and the abandon of the real spirit of what this document really represents. 

This article will present some of the most common pitfalls made in organizations while implementing Agile. My recommendation for you is to pay attention to each one of the items described below and to ensure that you avoid them to achieve a successful transition process. 

Mistake #13 – Playing the “Blame” Game

Scrum uses ‘Teams’ and not ‘individuals’ therefore it is hugely important that all team members will work together to achieve a common goal. As part of this approach, scrum teams will succeed or fail as a single unit; there is no room for blaming one person or another.

There is huge importance that the team will understand this from the beginning. Any other approach will not contribute to the sense of collaborative ownership, Innovation and a solid learning environment that will allow the team to grow. 

Mistake #14 –Unsuitable Physical Environment

Scrum embraces “Face-to-face” communication. Therefore, we must ensure the physical environment allows the Scrum team to work together in the same physical area (We must ensure the team will get the environment that will allow them to work as a single unit).

In addition, the environment must be a physically supportive so to allow the team to perform the different Scrum ceremonies. The location should allow the team to focus on the meeting agenda and to remove any external interruptions that can affect their concentration.

Mistake #15 – Bottom-Up instead of Top-Down

I saw so many implementations that completely fail due to the missing understanding that you cannot scale Agile prior to resolving the more basic issues that you will find in almost all Agile transitions. Once the organization decided to make an Agile transition, we should start by resolving the most common problems first; these problems related to communication issues, organization culture and the state of mind.

To allow the organization to scale an Agile project; you first need to resolve these basic issues, so try to start from Bottom-Up instead of Top-Down, once you have the building blocks at a team level, you can add the second level of scaling Agile. 

Mistake #16 – The Agile Mindset

There is a Hugh difference between ‘Doing Agile’ and ‘Being Agile’; the most important factor that differentiates between them is the mindset of the people involved in the process. Agile demands a different mindset from what people used to have in old traditional methodologies (e.g. waterfall).

Know this; you will fail to make a successful transition if your clients will keep their old habits that rely on a previous mindset. Your main goal should be to change this mindset by showing them the Hugh benefits of Agile. This includes why it is good for them as well as for the organization.

Mistake #17 – It is easy to do it if you understand it

I think that it is a basic assumption that people will be more dedicated to any change if they first understand the logical reasons that led to the change. People need to understand why Agile was chosen as the preferred approach to handle the organization goals and what are the ‘principles and values’ they will need to embrace in order to succeed.

Mistake #18 – Micro Management

Following the Agile manifesto, there is no room for micromanagement, scrum masters, Product Owners and even the scrum facilitators are not allowed to determine the amount of work that the team will accomplish per iteration, Assign tasks or tell the team members what to do.

Scrum provides ceremonies whose primary function is to increase visibility, communication and the transparency of the current project state.

Mistake #19 – Commitment is just a buzzword

It is simple, without real commitment you will fail at anything in life. This is the same as setting a goal to reduce 20Kg from your weight without making a real change in your current lifestyle. Agile is no different. To be able to make a successful transition, it is not enough to want it, people must be truly committed to the process with the understanding that they will need to make major changes in their state of mind and how they work.  Believe me, it is not obvious that people will agree to do it once they really understand the consequences.

Mistake #20 – Agile is a never-ending journey

I really don’t like to describe it as a mistake, but once you choose to be Agile you need to understand that it’s a never-ending journey of learning. It is most probably the best way for the organization to keep consistent growth.

Mistake #21 – Planning in Agile? What for?

Planning is a key part of any Agile project. This is especially important once we start to make a transition from traditional methodologies. The common pitfall I often see in many organizations is the misunderstanding that planning can be ignored because Agile does not use upfront planning, this is wrong!!

In Agile, there is no “Less” planning, the main difference is that we do it differently. Instead of doing one major planning at the start of the project (Traditional Methods), we now perform a “High-Level” planning at the start of the project and then consequently micro-planning is conducted rapidly prior to the start of each new iteration. 

Mistake #22 – Documentation in Agile? Really?

We are doing Agile, so there is no reason to use Documentation anymore! Well, No. although the Agile manifesto species that we should aim for a “Working Software” instead of “Comprehensive Documentation” it does not say anything about ignoring documentation or not using it at the different phases of the project.

The main difference in Agile is we can do it per iteration and not in a single static document at the start of the project (due to obvious reasons of maintenance and changed requirements that arise during the project).

Mistake #23 – Relying on “Best Practices”

In the last five years, I was involved in more than 50 Agile transitions that were made in both small and large organizations. During this time I come to a single conclusion that each transition is different, there are no best practices that you can take and enforce on one organization because it worked in another. Each transition is different because the factors are not the same for all organizations, just think about the organizational culture, team majority and the organization real readiness to make the change.

My best TIP that closes this article is to not use any “Guide” book, Checklist or “Best Practices” during Agile transitions. instead, investigate the organization, its state of mind, the organization needs and goals. Only once you understand these areas then you can start to build a worthy plan to perform a successful transition, any other solution will fail even before you had the chance to try it. 

Thursday, May 17, 2018

What does it mean to be an Agile tester? | Supreme Agile

In the recent years, the software industry has made a massive transition towards more advanced software development techniques. These are replacing the traditional SDLC methodologies that are now much less attractive for organizations. This is especially true for those that need to deliver their products faster in the consistently increasing competitive software industry.

If you are part of this world, you are probably aware that agile software development is the number one alternative method used by the organization. There are many reasons for this. The main reasons are that it embraces team collaboration, increases transparency, lower costs, increases ROI for the customer and has the ability to deliver product faster and within shorter timeframes.

However, this article is about testing. Therefore, it is more important to understand the new role of an 'Agile' tester in this “new world” 

The testing processes

In traditional testing, testers would start their tests (Dynamic tests, Static tests can start earlier) only after the coding phase was completed. The basic process was the test team receives a build that meets the testing 'Entry' criteria from their development team. Once received, the testers would run their preliminary written tests based on traditional test documentation such as STP/D. they would try their best knowledge effort and skills to uncover defects.

In an agile project, testers are involved in the project from the beginning. This includes many activities such as requirements (PBI's) gathering, working simultaneity with developers and the actual testing per iteration. This means the demand from testers has increased. The testers would need to have both the technical and personal skills to contribute to the team so they are able to deliver high-quality products.

What's An Agile Tester is all about?

An Agile tester should be a professional tester who has the knowledge and experience in the quality assurance (Tools, Advanced test methods Etc.) field. This would allow him to support and assist the team (That usually contains more developers) to meet the quality challenges the team may encounter throughout the project.

The Agile tester must be capable to work in a continually changed environment. Thus making the test effort more difficult and challenging than in traditional SLDCs (There is no time to prepare test cases with an unrealistic number of steps or even write an in-depth test plan).

The Agile tester must be a quick learner to understand the customer needs. This is in order to assist the PO and the team to understand the real customer software requirements. This would also allow him to facilitate testing for a particular sprint (Remember DoD of a user story will not approve without the necessary tests).

The Agile tester must have the correct attitude.  This is crucial to their ability to succeed as an agile team member. The correct attitude will allow the team to see another view of the product from a client perspective. It will assist the team to gain a better understanding of what the customer really needs.

The Agile tester must possess great communication skills. This is because there is no separation between the different departments any longer. As a team member, the tester will have to work closely with other team members, especially the developers. Therefore the tester must have the skills to drive testing in his team in order to increase quality, reduce technical debt and automated all tests that can be automated. 

Monday, May 14, 2018

Testers are not the "Quality" officers in a Agile teams | Supreme Agile

What makes a team really "Agile"? To me, an agile team is one that follows the simple values and principles of the Agile Manifesto but knows how to take them a step further. Although the Agile Manifesto created the foundations of all it’s frameworks (Scrum, EP, Lean Etc.), it’s still not a religion that the team should follow blindly.

An Agile team should have the power to learn new things. They should combine artifacts that work great in other frameworks, innovate new development techniques and find the balance between an Agile Spirit and what is more practical that works for them.

There is one thing an Agile team must follow and that is the simple mission that the customer is the most important stakeholder. Therefore the team should always focus on making on delivering the best possible product that meets the customer’s requirements.

From my experience, if a team focuses on this single mission.  It will formulate a team that will deliver the best quality product. In addition, the team will become disciplined (work as a single unit), always search for new learning materials to help them succeed with the project goals. Most importantly it would allow them to share their knowledge, experience, and skills with each other.

In conclusion, the most successful projects are those who focus on customer requirement, have a team of great people who worked together without any ego and senior management allow the team to maximize both their technical and personal abilities. 

And what about the quality owner?

Starting from the end, there is a reason I wrote this long introduction. If you focused on it, it should be clear to you why there is not a "Quality" officer in a Scrum team. This is because it goes against the whole idea of collaborative work. Quality is a state of mind, it starts from the very basic phases which involve all team members. If done correctly, the quality ownership jointly shared among all team members and not only the tester.

From my personal point of view, the Agile tester is just a new role name created to allow a more efficient transformation from traditional methodologies. Think about a company that worked in waterfall SDLC. The company had 100 pure testers in a single department, now the organization decided to start transitioning to Agile SDLC. This results in massive concerns rising from this department (You will see it in any transitions) about what their role will be in the new Scrum teams.

One option is to release all testers that are not suitable to work in this methodology (Believe me that if it was simple, you will saw it more often).  This is the least preferred option by most organizations. The second option, often used, is to "Sell" these kind of employees as "Agile Tester", "Quality Champion", Quality enforcer etc. (Ask yourself are there new names for other crucial roles such as "Agile Developer", "Agile DBA" or any other names that may sound better but just the same).

Let us be clear, the set of skills and personality that make someone great as a Tester within an Agile team is almost the same as those used in other SDLC methodologies. The main difference is that in an Agile team, the Tester is part of a wider team that includes also developers, analysts, DBA's and sometimes even other testers.

In addition, the Agile tester should not see himself as the team quality officer and this takes the responsibility for all quality related issues (It is a catastrophe ready to happen). 
Throughout my career, I have seen many failed teams seeking to “protect” customers from "terrible" team members who do not know enough about quality. From an Agile perspective, this is the last thing you want to hear from one of your team members.

A true tester in an Agile team (If it easier for you, call it an agile tester (AT)…) is a person who has the knowledge and experience to know that quality is related to all aspects of the project. Part of this includes full stakeholders involvement. If there are missing quality aspects, it’s become his responsibility to gather and share information about the missing quality artifacts. As part of this process, the AT can do it with the other team members or/and the product owner. The AT can also act as a bridge to other quality issues that may affect other teams.

Testers in Agile teams, as well as other team members who have the right skills and mindset, are continually looking for new ways for the team to do a better job of producing high-quality software. The main point here is to know that any team member can do it, this function/responsibility is not solely owned by the agile "Tester". It should be the effort of the entire team.

To conclude: the best Agile groups were built by developers, without any pure testers who had the current state of mind and understanding of the importance of quality.

Testers in agile teams, what’s next?

As I described at the beginning of this article, testers in Agile teams are just another team member who contributes to the main goal. Testers are not quality officers and are not solely responsible for the quality deliverables. The bottom line is Agile teams should include personnel who have the relevant skills and knowledge to meet the overall goal of the project as well as quality objectives.

Testers in agile teams, like their agile teammates, enjoy acquiring new knowledge and skills that allow them to undertake new challenges from project to project or even from sprint to sprint.  Testers should NOT limit themselves to handle only testing issues. This would be a Hugh mistake for both them and the team. Testers must view themselves as equal to any other team member that can address any kind of issue that might arise during the project (as long as they have the necessary skills, experience, and knowledge).

Agile teams can benefit from their testers (again, only if they have what it really takes to be part of the team) in many different areas such as: 
  • Testers can provide some great insights into what it takes to improve the quality of the product.
  • Testers can help to define the "Definition of Done (DoD)" of user stories.
  • Testers can add creativity and new ideas to perform a robust testing process.
  • Testers can help the team to design, Write and execute both manual and automated tests.
  • Testers can help the team to understand the testing scope of PBi's to provide better time estimations.
  • Testers can participate at all levels of the project and add their vision about the project requirements, Design and testability.
  • Testers have an instinct and wide understanding of where and how the software might fail. Therefore, can assist the team developers to write a better code.
  • Testers can help other team members to write tests in different testing layers (Unit, Component, integration, and system).
  • Testers should have a wide perspective and vision about the product, as such, they can assist the team and the PO to create more elegant solutions.
  • Testers can do test reviews for other team members to ensure good coverage and testability. 

Wednesday, May 9, 2018

Traditional testing vs. agile testing | Supreme Agile

Throughout my professional career, I find myself often asked what is the difference between the Agile and the traditional methodologies? This is especially true when it relates to testing.

To answer the question, let us begin by looking at similarities between Agile testing and testing in traditional software development (SDLC).

Traditional Testing (Waterfall)

The SDLC waterfall model is the most commonly used methodology in the software development industry for those organizations that still use traditional SDLC methodologies. Let's examine it by reviewing its all the phases prior to go-live (i.e. release) and maintenance.

Phase 1 - Requirements Analysis
All requirements for the software are captured in a specific software requirement specification (SRS) document.

Phase 2 – Design
Development teams will learn the requirements captured in the SRS document and then create the system design specifications (System Architecture, Flows, Hardware, Etc.).

Phase 3 – Coding (or commonly known as Build)
The development team will use the system design document and start to develop the software (Data layers, Services, Procedures Etc.). The basic development cycle is to start with the units, modules that will integrate into advanced development phases to create the system.

Phase 4 – Testing
The system that was developed in the coding phase is now delivered to QA teams so they can run "Functional" and "nonfunctional" tests. During this phase, testers will report software bugs that will need to be resolved by the Development Teams.

As you can see, this model is relatively simple. It is clear that testing happens only at the end, just prior to release. Now, if you not familiar with this approach you may get the impression that there is as much time for testing as there is for coding. 

Well, based on my experience this is not the case. The testing 'Entry' and 'Exit' criteria get squished because in almost all projects the coding phase will take longer than it was expected to end, and from the other side, the testing phase needs to end sooner because the customer will push the organization for early delivery. 

Agile Testing

Agile is an iterative and incremental approach. Agile testing is a software testing practice based on the 12 principles and 4 values of the Agile Manifesto. It covers all layers and all types of testing.

Agile testing involved the entire Agile team including DBA's, Developers and testers. Testing in Agile may look similar to what we saw in traditional testing but it’s not! In Agile, testing is NOT a separate phase, but rather the test team will test each increment of coding once its ready (interwoven of all development phases as we saw in the waterfall model) 

An Agile iteration (Aka: Sprint) might be as short as one week, or as long as a month (Two weeks is the classic amount of time that is used by most organizations). During this time, the team will return the same four phases (See waterfall model) to build a working high-quality product and then move to the next piece that needs to be delivered (The entire team will work together simultaneity to meet the story "Definition of Done (DoD)" that includes testing). 

Another important point is that testers are active participants in the entire software development lifecycle (SDLC) in conjunction with cross-functional team members. (I will publish a dedicated article about model 'T'  as the best way to build great Agile teams). These people will contribute all the necessary effort towards building the software as per the customer requests, with less effort, better software design, increased ROI and the delivery of high-quality software. 

Focus on the things that matter

Testing is a mandatory part of any project no matter how big it is. In agile, testing may refer to Epic, Feature and User story (As you will see, the focus is on stories). No matter where you choose to start, the team will need to ensure it has a high-level understanding of it (Similar to what testers will do in traditional testing).

Agile testing will allow the team to focus on small PBI's without the need to come up with a massive test plan or test strategy for testing as is usually done for traditional approaches. The team can focus on creating testing per PBI instead of creating tests on the basis of one SRS document was created by Product Management/Business analysts before anyone even wrote a single line of code.

Working at the PBI level will allow the team to design and execute the tests after they have a precise knowledge of how Dev will implement the code and what is needed to be done to ensure quality. 

Acceptance Testing

The basic definition of 'Acceptance testing' as it published in the ISTQB guide is "formal testing with respect to user needs, requirements, and business processes conducted to determine whether a system satisfies the acceptance criteria and to enable the user, customers or other authorized entity to determine whether or not to accept the system."

Now that we understand the importance of this tests for the success of the project, let’s see some of the major differences between the two test methodologies. In traditional testing, the acceptance tests are made by the customer and not by the team and only after the software has been released (Do you feel the Pressure? The panic? The Risk?).

In agile testing, acceptance tests are made by the team on an iteration basis, the team will follow a DoD that will ensure that the team will follow all criteria to meet the expected quality. So, this makes a Hugh difference, the team can perform the tests during the iteration and prior to delivering the product to the customer which will reduce the risk and pressure.

Adaptive to changes

As you already know, in a traditional testing environment a test team will have all the knowledge they will need at the start of the project once the SRS and HLD docs are ready. In Agile testing this is not the case, every PBI may involve a different type of challenge for such cases A team should be adaptive and solve it based on the tools, knowledge and the resources available (As an Agile team member, you must be able to meet this type of test environment and adapted to whatever the team's needs). 

Documentation is not the main goal

In traditional testing projects, the test team will create an endless test documentation (STP, STD, Etc.) contains test scenarios, test cases and the expected results of each test. Now when you have weeks and sometimes even months to invest in this exhaustive test documentation it may become reasonable, but in Agile testing, this timeframe is narrowed to few days and sometimes even hours.

Now, if you ever worked in a traditional testing project, you already know that this approach has some major disadvantages, such as:
  • Test teams cannot really create effective test plans for weeks and even months of testing while relying on written documentation.
  • The creation of massive test plans will not worth the time spent to write it down (Think that this time was invested in the actual testing process).
  • Writing down comprehensive test documentation will not benefit with the team morale (I never saw a tester that enjoyed to write thousands of tests that may be worthless once the actual testing will start). 

So, is there a test documentation in Agile? Yes, there is. The difference is in the size, complexity and the amount of time that invested by the team to create it (the team will focus on the essence of the tests rather than a comprehensive writing of its details). 

Instead of writing a detailed functional test scenario that will consume a time that the team does not have to spend, team members will conduct their tests based on more advanced testing methods such as Exploratory Testing (ET) and Risk-based Testing (RBT) which will allow the team to run more efficient and advanced testing process. 

Collective responsibility for the quality

There are so many jokes about the difference between testers and developers when it comes to software quality, the origin of these jokes are related to traditional testing. Let's explain it, as you saw, traditional testing has two different phases that separate testing from coding, as a result, each department is responsible to a single aspect of the software (Developers to create the code and testers that will test it).

In agile this separation does not exist. This is because the entire team is responsible for the quality factor (the main focus of the team is to produce quality software in a limited timeframe that maximizes its value to the customer). In some cases, developers will execute manual tests and automated tests. These developers will work with their testers to guarantee the software delivered is of high quality. 

Quick feedback from testing

The most important difference for testers in an Agile project is the fast feedback generated from testing that is just crucial in the overall effort of pushing the project forward. A good Testing feedback allows the team to understand the quality of the code and change it faster than it will ever be in traditional testing projects. 

Test Requirements 

I think you will agree the foundation for any project are the requirements, no matter what the chosen test methodology is. Below I have listed the main differences between Agile testing and traditional testing. 


Traditional Testing

Agile Testing

Who's responsible to write the project requirements?

Product Manager (PM), Business Analysis (BA)

Product owner with the team will write both the "Functional" & "Nun-Functional" requirements

When the requirements are written?

Once the project start (As we saw in the first phase of the waterfall model)

Every day during the project (Planning meetings, Sprint 0, refrainment meetings Etc.)

Ability to absorb changes

Almost impossible once development starts, each change will have a severe effect on Eng. teams

Requirements are changed frequently to allow the team to provide a better product to the customer


Requirements are created for the whole scope of the project

Requirements are created for a partial scope of the project (Usually enough for 3-5 sprints)

Type of writing

Very detailed including test inputs, steps, and expected results.

In the spirit of the used test techniques such as exploratory testing, there is no need to write detailed information.

Keep the code clean

In traditional testing approach, The Test team will report software defects. These defects will be fixed only after the coding phase is done. Therefore, the more bugs discovered will mean more fixes and more risk added to the project. In Agile, defects are fixed as they are raised in the same Sprint. The ability of the team to handle all defects in short iterations will reduce the risks and increase the team's ability to create clear and more resilient code and ultimately better, quality deliverables.

One last comment, in some cases not all bugs will be fixed in the same iteration. It is a common practice that the Product Owner will review (with the Team) opened bugs and will decide which bugs are more important than others. Using this process, the team will handle an only partial number of bugs that will not affect the DoD and the quality of the developed code. 

Sunday, May 6, 2018

Delivering without a scope in agile projects | Supreme Agile

In traditional projects, the 'Scope' reflects the answer to two main questions of the 'What should be delivered?'  and "How will it be delivered?", it's the constraints that keep the organization from exceeding the requested scope as asked by the customer (What + How = Project Scope).

Let’s say that your project is to deliver a three layer of a chocolate cake, in that case, the "What" will refer to the "Chocolate cake" and the 'How' will refer to the effort that goes into preparing the cake (Materials, stove, recipient Etc.).

The scope is a very important constraint in regardless the project management approach, but the importance of the scope is reflecting more easily in traditional projects where you can hear the very common phrase of "If it's not in the scope, it’s not in the project". In traditional projects, the organization and the define the scope at the start of the project and prior to many other important aspects such as the schedule and budget.

In traditional project management, these three aspects (Scope, Schedule, and budget) are also known as the "Iron Triangle". In this 'Triangle' each one of the three corners reflects one aspect from this list but also determines the correlation among them (Change in one aspect will affect the other two). Just for example, if the project schedule is changed, the organization will have to change the scope of deliverables and the budget that they can invest to make it happen.

The scope of Agile Projects

if you familiar with the agile manifesto and it's 12 core principles than you already know that the project scope is a variable that is expected to be changed "Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage".

In agile projects, the scope is just another variable that comes after that the organization has determined the costs and schedule at the beginning of the project. The schedule and costs are based on the customer that determines when he wants to finish the project and how much he's willing to pay for it.

Once the organization has these two variables of budget and schedule, it’s time to determine the project scope which is the responsibility of the team to add the relevant stories (Functional and nonfunctional) to the product backlog.

When the project starts the budget and schedule are supposed to remain constant throughout the project, in agile, there is no release date for the completed scope, the customer will receive all the scope they pay for based on what is prioritized by the product owner and within the original constraints. 

Agile Quality and Value

In agile, the quality and value are a key factor in the project scope. The agile team cannot deliver low-quality deliverables that will encounter the agile definition of done (DoD). They must ensure that each incremental release will meet the quality standards as specified in the DoD, if they fail to do so, it may break the trust between the organization and the customer and affect the future of the entire project.

To ensure that the team can deliver high-quality releases, the project scope must already include the time and effort the team will need to invest to meet the Definition of Done. This is the only way to allow the team to deliver working software under narrow timeframes and with the expected quality.

To see the difference between the two methods (Traditional/Agile), let's develop an ATM machine:

Traditional ATM (Scope, budget, and schedule at the beginning)
In this project, the organization will determine the scope, budget and schedule at the start of the project that will include a detailed plan prior the team start to work, the plan will include the hardware specifications, ATM Functionality and anything else that they will need to complete the project. 

Agile ATM (Budget, and schedule at the beginning)
Now let's take a look on how the same variables are different when using the agile project, the budget and schedule defined at the start of the project, for example, the project costs should not exceed 1M$ and the ATM should be delivered in 3 months.

The remaining variable of the project scope is still not defined at this point, the project scope will be determined only when the development team will start to work on the project and add their PBI's to the product backlog. Once the team adds their PBI's, it’s time for the product owner to prioritized which items should deliver first to increase the ROI.

Changes are here…!
Now, let's say that the customer wants to add/modify an ATM functionality, in the traditional project the scope is already defined and based on a fixed price and schedule that sighed with the customer, this will make it almost impossible for the team to add these new requirements (Remember that schedule and cost already been used during planning phase).

In agile projects the scope is flexible enough to add these new requirements and to allow the product owner to re-prioritize the product backlog and deliver the exact scope that the customer asks for (The same timelines and budget are kept, but the customer will get a different ATM than he asked at the beginning of the project). 

Tuesday, May 1, 2018

Choosing a sprint length - Which one is Better..? | Supreme Agile

A frequently asked question that I hear in almost any agile project is what should be the “length” of our sprint? One week, two weeks… and what is the benefit of selecting each length. So, if I want to provide the formal answer I can choose one of the two options: either “A sprint is a fixed time period, from one to four weeks, with a preference toward shorter intervals” (Scrum Alliance) or “The heart of Scrum is a sprint, a time-box of one month or less during which a “Done”, usable, and potentially releasable product Increment is created. 

Now, as you can see, these two written answers will not help us to understand how to choose the correct sprint length of our project, and even more important, what factors should we use prior to providing real answers to our customers. 

Prior to us moving forward, I want to explain the spirit behind these two answers, if you familiar with the Agile manifesto, the team is above all, and this is just one example that demonstrates this because it leaves it up the Scrum team to decide what is the sprint length that will work best for them. This is what we see in most Agile transitions, the experiment with sprint length to determine the best and the most efficient length that works for the team.

In this article, I will provide some guidelines, Tips, and thoughts that will clarify some of the biggest concerns that we are facing while choosing the sprint length.

Main Factors to Consider

There are some basic questions one needs to answer prior to determining the iterations length. The answers to these questions will help us to see the big picture and the most important factors that we need to consider: 
  1. What is the complexity of the project? 
  2. How many teams do we have? 
  3. What is the expected duration of the project? 
  4. What is the organization experience in scrum? 
  5. What are the deadlines that determined by the customer? 
  6. What is the organization culture? 
  7. How responsive the customer is?
  8. What is the team experience in Scrum? 
  9. Do you have the necessary knowledge to handle the job? 
  10. Do we have the Environment factors to support the chosen length (Tools, Frameworks Etc)?
  11.  Do we have supported architectures (Automated frameworks, build system, CI Etc.).?

Advantages Vs Disadvantages 

Short Iterations (1-2 Weeks)


  • More retrospectives will lead to more efficient and faster improvement of the process.
  • Short iterations will lead to more pressure that is put on the teams, this pressure (Believe it or not) can help high-performance teams to form even better. 
  • The Product Owner will have an easier work while prioritizing the product backlog.
  • More reviews give the product owner the opportunity to provide more feedback.
  • Short iteration will allow the team to make a much more efficient planning.
  • More reviews will lead to more feedback that generated towards the team.
  • Short iterations will help the team remain in focus during the iteration.
  • Impediments reported and mitigated more often, which will help to increase the principle of, continues improvement.
  • Short iterations will reduce unnecessary Risks that may affect the team.
  • Short iterations will help the team to reduce deliver faster.
  • Short iterations will force the PO and the team to create short stories that can fit into a short iteration (Small stories are easier to estimate and will increase the team capability to deliver them).
  • Short iterations will allow the team to make much more precise estimations and to increase predictability.
  • Short iterations will make it easier for the team to embrace and understand the agile values and principles. 
  • Most Agile coaches (including myself) recommended the use of short iterations. 
  • Most organizations are working with short iterations. 
  • Shorter iterations will allow the team get its capacity and velocity sooner. 


  • The biggest and most common issue is the “Overhead” that comes with so many meetings that are a mandatory part of the Scrum framework. This issue relevant for both new and experienced teams and can severely affect the team performance.
  • Especially in non-experienced teams that are new to agile, shorter iterations can make team member more stressful due to the short delivery dates.
  • In many cases, Two weeks iterations will make it harder to deliver a high-quality product (Although experienced teams can easily overcome this issue).

Long Iterations (3-4 Weeks)


  • When moving from traditional methodologies to agile, it easier to start with longer iterations that will help the team to adapt the concept of iterations. 
  • Longer iterations mean more work that can be added which may increase the team ability to release a real shippable functionality per each iteration.


  • The product owner has more opportunities to add more work to the teams.
  • Is it I or longer iterations can lead to mini waterfalls..?
  • The longer the time the team invested in the work, the less focus is generated.
  • Longer iterations will reduce the review meetings that is a key factor in the capability of the product owner to improve the product.
  • Fewer review meetings will reduce the feedback that is generated by the team.
  • Longer iterations mean more opportunities for external and unexpected interruptions.
  • Longer iterations will extend the time almost any scrum ceremonies and plan in particular (Hugh HR killer for the team!).
  • Fewer retrospectives that make it, harder to embrace the concept of continues imprudent.
  • It just makes it harder for the team to forecast the amount of work they can deliver.
  • Longer sprints mean more changes that may arise during the iteration.
  • Iteration of 4 weeks…seriously…? Is it really “Agile”...? 

My Presentations