Monday, December 25, 2017

What is a Sprint in Scrum? | Supreme Agile

תוצאת תמונה עבור ‪scrum sprint‬‏
According to the Scrum methodology, development cycles are called " Iterations" and with the other and more familiar nickname of "Sprints". These development cycles are relatively short and can go anywhere from a week to a month (Most organizations iteration with a length of two weeks).

During each development cycle, the team collaborates as a single unit to deliver a working part of the software based on the customer demands and expectations. At the end of each sprint, the team will present the accomplished work (A.K.A: User Stories) and right after that review a new iteration that based on new tasks can start.

What is the idea behind this short development cycles?

The answer is simple when the team needs to take commitment to a long-term task they will not be able to see when it ends. Now, in most cases, the team will provide an Eta, but the problem remains the same, the team does not have the ability to take real commitment because no one can foresee the problems, challenges and new tasks that can arise during this time that will reduce the focus from the main task.

To resolve these problems, scrum uses short iterations that are restricted in time and in the number of tasks that the team will perform which will allow them to remain focused on short-term tasks without the need to foresee the future work month ahead. 

In addition to the above, we can see some other great advantages for using the method of short development cycles:

  • There is more room for handling issues that arise during the iteration.
  • The team will determine the amount of work that they will do per iteration, this sense of ownership will help to increase their sense of commitment. 
  • The team will commit to only the amount of work that they can deliver. 
  • The team will use a set of structured meetings: Daily Scrum that will allow them to remain focused on the iteration main goal, Planning meeting that occurs at the start of the sprint to understand the requirements, challenges, and expectations prior to taking any commitments that based on the team capacity and velocity, Retrospectives to improve and adapt the process for maximum efficiency, and review meeting that will allow them to get real feedback about the quality of their work.

The Main Phases of a Sprint 

Phase 1: Determine the Sprint Backlog and Team Commitments

Every sprint begins with a planning meeting (Pre-Planning meeting may be also used), which involve the entire scrum team, during the meeting the team discuss which user stories should be added to the sprint backlog, the decision is made based on the prioritization of the items in the product backlog (PO) and the team velocity that determines the amount of work that the team can handle in a single iteration.

The sprint backlog is a set of stories that should be delivered by the team at the end of the sprint, each story that is added to this backlog should be approved by the team prior to taking any commitment to deliver it.At the end of this phase, we have prioritized sprint backlog, updated product backlog, known goals, and set of commitments made by the team.

Phase 2: Sprint Execution

The team will work together to finish their commitments for succeeding to meet the iteration goal. Their work will include different activities such as Design (HLD/LLD), Coding (TDD/Continues integration Etc.) and testing (Risk Based testing/Exploratory and Automated testing on different layers of the code (Unit, Component, Integration, and System)).

In addition, this phase also includes the daily scrum meeting that will help the team to synchronize about the remaining work and to ensure that everyone stays in focus regarding the iteration goal. 

Phase 3: Iteration Results

Once the iteration is completed (2-4 weeks), the team will demonstrate the potentially shippable product increment to the relevant stakeholders (Product Owner, Customer, Etc.).

Phase 4: Continuous Improvement

At last, the team also performs a retrospective meeting at the end of every sprint to discuss on how things went and what can be improved in future sprints.    

Wednesday, December 20, 2017

The Burn-Down Chart as a Fundamental Metric in Agile | Supreme Agile

תמונה קשורה
The Burndown chart is a fundamental metric in agile, the metric presents the team progress in completing the committed user stories and it provides a quick view of when we can expect to be done. The main parameters in this graph are the amount of work reaming (usual story points or days) and the time remaining until the end of the iteration.

The Burndown chart should consist of:
  • X-axis to provide information about the iteration working days
  • Y-axis to provide information about the remaining work
  • Ideal effort as a basic guideline for the effort need to be completed.
  • Real team progress of effort

The burn-down chart is the main tool of the team to provide viability about the state of the project because it can answer the main questions that asked during any project: 

Types of Burndown Charts

Sprint Burndown Chart

The Sprint Burndown chart is a visual measurement too, that provide a quick insight into the completed/remaining work per day for the current sprint.  Benefits:
  1. Provide a quick review of the team effort.
  2. Will allow the team stakeholders to take fast decisions based on the graph results (that will help to remove impediments that are affecting the progress).
  3. Provide daily feedback on the team progress.
  4. Provide transparency to the team performance.
  5. Help to determine if the team can accomplish the sprint goal.
  6. The main communication tool for customers and product owner. 

Release Burndown Chart

In scrum, the release is determined by the delivery of a product from development to the customer. A release Burndown chart helps the stakeholders to get a very good view of the release progress by determining the amount of the remaining work (X-Axis = No of sprints, Y-Axis – The remaining effort). 

How the Burndown chart is built?

The Committed Work (Y-Axis)

Prior to starting a sprint, the scrum team first selects a number of user stories they want to accomplish, the process of analyzing, Prioritizing and Estimate the PBI's is done in a dedicated meeting called "The Planning Meeting" that is done prior to the start of each sprint. To get the work estimations, we need to combine all estimations of the PBi’s committed by the team (Y-Axis).

The Iteration working days (X-Axis)

The X-axis represents a unit of time (2-4 weeks) represented by days, by following this axis, we can determine the amount of work completed for a specific time. 

What is the Total Work Estimate?

The total work estimate is the sum of the efforts (Hours) of all the user stories which the team is committed to.

What is the Remaining Work Effort?

This question can explain why this graph gets its name (“Effort Burndown Chart”), by looking at the graph, we can get an instant look at the effort made by the team per day.

What is the Amount of Working Days?

The question can easily be answered by just looking at the graph that shows the total days of commitment of workdays (Sprint Duration).

How Much Work Done by Now?

The graph also present the amount of work that the team accomplished through a period of time (This data can be also used to predict the iteration future progress).

What is the team velocity?

The graph can provide an instant look at the current team velocity, the calculation is made based on the work done for a given period of time.

Can the Team Add More Stories to the Iteration?

If the PO decides to add more work to the iteration/project, the team can instantly review the burn-down chart and see the impact that the new demands on the current delivery date.

Burndown Chart Team Scenarios

Although the Burndown chart contains only two lines, there is a major importance to understand the different situations they describe. These situations are probably the most common (Depends on the quality and experience of the team):

The Role Model team

This team characterized by two major qualities:
  1. Has the relevant experience (Technology/Agile).
  2. The team is familiar with the importance of agile commitments.
  3. The team can adapt interruptions that may arise during the iteration.
  4. The team embraces the retrospective meeting to achieve continues improvement per iteration.

Although the team started with some gaps, they manage to resolve all issues and complete the iteration on time. In addition, the team will use the retrospective meeting to resolve all issues appeared in the last iteration to become better in the next iteration. 

The Ideal Team

The Ideal team characterized by three major qualities:
  1. The team is able to organize itself.
  2. They know their velocity and boundaries, and therefore will not commit to a number of user stories that will lead to “Over-commitment”.
  3. They have the ability to estimate capacity correctly to remove the unnecessary loss of working days.

The Burndown chart of this team will indicate that the team has finished all commitments on time. 

The Average Team

The average team is a team that is able to complete their commitment and iteration goals. Based on the represented graph, we can see that the team is able to adapt to the delay they had during the iteration and work harder to complete the remaining work.

This graph is more common for experienced agile teams for the following reasons:
  • They don’t panic once they have an unexpected delay.
  • They know how to adjust to the new challenges and hard work that they will need to perform to meet the iteration goals.
  • The team knows how to prioritize the iteration stories (Low prioritized stories return to the product backlog).

They have good communication skills that allow them to take decisions immediately as they see the delay from the beginning of the iteration. 

The Team that Can Do Much More 

There is a good reason way team commitments are so crucial in agile software development, the main reason is that once the team is committed to delivering a set of stories, the expectation from the other stakeholders is that the team will deliver what they committed to, simple as that.

The Burndown chart can reflect unaccomplished commitments in a very easy and graphical way, but in addition, it can tell us when the team fails to adopt the iteration scope to a work level that will allow them to meet the top prioritized stories.

It is very important for the team to take active corrections once they discover that they cannot handle the work capacity (you will see it once there are a few days of slower progress), the most common corrections are:
  1. Move user stories to the product backlog (for re-estimate/Prioritize).
  2. Move user stories to the next iteration (If the priority remains high).
  3. Split stories to smaller units.
  4. Reduce the next iteration capacity (There is no reason to set the same capacity if the team cannot handle the work effort).

The Nonfunctional Team 

The graph of such team will present a scenario that represents a catastrophic picture about the team performance that may arise from many reasons:
  1. The team is not committed to the process.
  2. The team is not coached enough to track progress on a daily basis.
  3. The product owner does not care about the work done by the team and therefore does not ask any questions.
  4. The scrum master fails to enforce the agile spirit and practices throughout the iteration.
  5. The team does not update their daily progress on purpose.
  6. The team does not do an effective retrospective meeting that mitigates wrong behavior. 

The Team that Ignoring Work Estimations

In this scenario, the iteration Burndown chart will indicate that user stories (and the associated tasks) were not estimated during the iteration-planning meeting and added to the iteration without time estimations.

To fix this situation, the team should immediately arrange a planning meeting, estimate the user stories, include them in the sprint according to their velocity and start the sprint.

Team With Over Commitments

This graph represents a team that took a scope of work that is too big for them to handle, as a result the team fails to meet the iteration commitments.

The Team that Overestimated the Scope of Work

This graph represents a team that finishes its work earlier than they expected but didn’t take corrective actions, such as work on additional stories from the product backlog (Although they had the capacity to handle it).

The Team that is Not committed Enough

Although the team will succeed to finish their commitments and meet the iteration goal, the Burndown chart display a problem in the team behavior, this problem is related to one of the following reasons:
  1. The team is less committed and took a break in the middle of the sprint (Although they have more capacity to extend the work effort).
  2. The team committed to fewer user stories, although the team velocity allows them to add more work.

Monday, December 11, 2017

Proper Product Backlog Prioritization | Supreme Agile

תמונה קשורה
The backlog prioritization process is crucial for any agile project, during this process, the product owner will decide the importance of the user stories resides in the product backlog and prioritize them in a way that the most valuable stories are at the top of the list and the less important stories will be ranked at the end of the list. 

Without the prioritization process, there is a slim chance for the team on not delivering what the customer really needs, and that's not reflecting the agile spirit of delivering real value to the customers, By the agile manifesto:

"Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."

Now it makes sense that we want to deliver value to the customer (After all, he's the one the pay the money…), but in addition to that, the prioritization process will also help the scrum team to understand the customer expectation and basic guidelines for the work effort they will need to invest per iteration. 

Who's responsible to prioritize the product backlog?

As I mentioned in the beginning, it's the product owner's responsibility to ensure and validate that the product backlog is prioritized which make sense due to the fact that the PO is the one that has a direct approach to the customer. 

Now, can the product owner do the prioritization process without involving the team? No, like any other refactoring activities, the prioritization process must involve the entire scrum team, this is the only way to guarantee that the prioritization process will become more productive and effective.  

When to Prioritize?

The backlog prioritization process should be performed continuously throughout the project, there are no "Best Practices" for it, the prioritization will start once you create the initial product backlog and add the user stories, and continued prior to each iteration.

The prioritization factors

The product owner and the scrum team should prioritize the product backlog prior to the start of each sprint (Usually in the refinement meetings), but what are the main factors that they are using to decide which user stories are more important for the next iteration and which will be left in the product backlog?

The value to the customer

The first and most important factor that should be used in the prioritization process, is the Value that the user story adds to the customer, simple as that stories that have the bigger value should get the highest priority. In scrum, the team has iterations of 2-4 weeks, therefore the team must be focusing on delivering the highest value in relatively very short time.

A user story becomes more valuable based on the amount of contribution in bringing the project to life, if the user story has a low contribution in promoting the project deliverables than it becomes less valuable (These stories are Re-prioritized and placed in the bottom of the product backlog) than stories that contribute more in promoting to the future incremental releases.

Now, the "Functional" stories that add value to the customer are crucial, but that's only one side of the story, the second side is the "Non-Functional" stories that mostly added by the scrum team and does not add a direct value to the customer, these stories are added by the scrum team to improve productivity, handling external interruptions and another type of task that does not add a direct value to the incremental release but help to improve the team ROI.   

Risks and Uncertainty

The risk factor implies the amount of "uncertainty" that mostly caused by the team lack of knowledge. The less the team knows what to develop and how they should do it, the higher the risk and uncertainty. 

User stories with high risk and uncertainty have a major influence on the project and especially on the team commitments that must be delivered within a very narrow time frame, therefore those stories should be marked with high-priority to accelerate the generation of a new team knowledge in this area of expertise, Remove uncertainty and eventually to reduce risks early as possible.

Costs and ROI

Costs are a major factor in the product owner's (PO) ROI calculation. The main reason for that is that in some cases the most desirable stories might cost too much to develop, which resolve a negative ROI. 

The ROI calculation has a major value once the product owner needs to decide which stories should be delivered first, based on my experience, two equally important stories are often prioritized by costs; the story that has the lowest-Cost and positive ROI is given higher priority.


Dependencies in the product backlog are a fact, although we should aim to create standalone stories, there will always some dependencies among them, the dependency can be related to both "Functional" and "Non-Functional" stories. Dependencies must be taken under consideration once the product owner should decide how to prioritize the product backlog because, in some scenarios, high profile stories cannot be developed because of a dependency that must be removed prior the team can start to work on that story.

Monday, December 4, 2017

The Agile Manifesto - 4 Agile Values Explained | Supreme Agile

תוצאת תמונה עבור ‪agile values‬‏
The agile software development approach was created back then in 2001 with the publication of the Agile Manifesto, a document containing the principles and overall spirit of this new approach. The agile manifesto contains four main principles that are used to this day in any software development process that based on one of the agile methodologies (Scrum, Kanban, Extreme Programming (ET) Etc.).

The four principles are:
  1. Individuals and Interactions more than processes and tools
  2. Working Software more than comprehensive documentation
  3. Customer Collaboration more than contract negotiation
  4. Responding to Change more than following a plan
By creating these principles, the creators determined the although the values located on the right are very important, we still need to prefer the values from the left. Now, a very important thing that we must raise, is that this approach is relevant only in case of conflicts that may arise during the project. 

In this article, we will try to understand the logic behind each one of these principles:

Individuals and Interactions more than processes and tools

In order to promote a project, the stakeholders must use a dedicated and specific process and management/Development tools that will help them to accomplish the project goals. 

That's just a simple fact that we cannot deny.  However, the agile approach reminds us that there some aspects that even more important such as face to face communication, Trust among the relevant stakeholders, Self-Organized teams and more. 

Without these basic aspects, we will most likely fail to promote the project agenda that based on human resources, regarding the quality of the process and tools used on the way. 

Working Software more than Comprehensive Documentation

The traditional software development methodologies are built on the belief that there is a need in heavy detailed documentation process to handle each phase of the project. This could be fine and appreciated, but the biggest problem occurs once the documentation becomes the main goal of the team instead of focusing on delivering a working product.

The value of a "Working Software" is one of the most important concepts in agile, and therefore it gets a Hugh focus throughout the agile process. 

The main example that demonstrates this issue, is the concept of providing an increment software release in a very short development cycles (2-4 weeks) without the need to invest a major effort to document every step in the way that leads to it.

Customer Collaboration more than contract negotiation

To achieve success in almost any field, we first need to understand the expectations of the other side, this is the same thing in software development process, where we need to collect the customer requirements (Expectations) that are used as the baseline for the future development process. In traditional software development methodologies, those requirements are defined at the start of the project subject to the contract signed between the customer and the company. 

Sounds good, but what happens if the customer needs to change the preliminary requirements once he realizes that there is a gap between the original requirements and his current needs? Well, this is the problem! Due to the original contract signed between the two sides, each modification in requirements will resolve a contract modification, that in most cases will be denied by the company and will not allow the customer to get the product he really needs.

In agile, we still use contacts, but with one major difference, now the contracts are signed with the purpose to work with the customer and based on a collaborative communication that will allow the customer to modify the preliminary requirements without the restrictions as we saw in traditional models.

Responding to Change more than following a plan

In the traditional software development methodologies, we had clear phases that include a massive amount of planning that we will use for the entire lifecycle of the project. If we look at the "Waterfall" methodology that is probably the most commonly used in companies that are not using agile frameworks, we will see that there are five phases (Requirements -> Design -> Implementation -> Verification -> Maintenance), that are used during the SDLC.

Now, although each phase makes sense in the SDLC, there are some major problems that are driven by the nature of these models, Examples: 

1.   There is no option for to start a next without fully completing the previous one.
2.    There is a Hugh amount of planning per phase.
3.    There is almost zero tolerance to absorb modifications in project requirements.

So, what is so different in agile? The main thing is the understanding that ongoing changes in requirements are just another way to allow the customer to get the product that he really needs, therefore, the spirit of agile is to accept and embrace the ongoing requirements and the deep understanding that this is the best way to provide the best and most suitable product for the customer. 

The true agile spirit is based on the capability to flow with ongoing changes and not blocking them, by following this spirit, we will allow the organization to achieve some Hugh advantages that will provide a solid ground for greater collaboration with the customer.  

Saturday, December 2, 2017

Scrum at a Glance | Supreme Agile

תוצאת תמונה עבור ‪and that. gentleman, is scrum‬‏

The methodology of Scrum, is the world leading agile methodology for managing product development, especially because it's very lite, simple and flexible method to manage projects. The scrum framework provides a set of roles, ceremonies, and activities that based on the 4 values and 12 principles described in the agile manifesto:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

You can review the 12 principles as described in the Agile Manifesto:

Why it Called "Scrum?"

The origin of the term "Scrum" related to the world of rugby which is a team sport, the official definition is "Restarting play after a stoppage which has been caused by a minor infringement of the Laws".

So how it’s related to the world of software development? Well, there is one Hugh aspect that we can consider as crucial for the success of any team, and that's the "Human Spirit" that allow the team to rise above any barrier that can affect their success.

This factor can easily reflect the main idea of Scrum, of creating a cohesive team that will combine sets of individuals that will work with harmony and collaboration that will increase the efficiency of the team compared to a set of individuals that concentrates on their own success.  

Scrum Uses four Main Principles: 

Iterative Approach

Based on this methodology, the teams will now use short iterations that will include the same activities as we saw in traditional models, the main idea that similar to "Scrum" is that the team will start a new iteration (With new tasks) right after the previous sprint has finished.

Incremental Releases

After each iteration, the team will deliver an incremental working release of the product.

Building Team in scrum

The scrum team is built from sets of individuals that each one of them can perform tasks related to different areas, the team is self-organized and can handle tasks based on the iteration capacity.

Empirical Process control

Scrum uses an empirical process control that bases on the real-world progress of a project and not based on guesses or long forecast as used in traditional methodologies.

What differentiates Scrum from other methodologies?

The Scrum framework is differentiated from both agile and traditional models due to the following reasons:

Real Agility

The main advantage of scrum is that it allows the organization to manage projects with the ability to make adjustments based on the current progress and completed work.

The roles

Scrum has three core roles that are responsible for the main aspects of the projects, the roles are Product Owner (PO), Scrum Master (SM) and the Development Team. By using only three main roles, the framework provides a great simplicity that will reduce the bureaucracy and time to make project decisions.

Iterative Model

Both large and small projects are divided into small iterations (2-4 Weeks) that allowing both the team and the customer to make sure they deliver the product asked by the customer.

Communication and Collaboration

The scrum framework contains a few basic ceremonies that increase the close communication between the project stakeholders. The ceremonies are known as Daily meetings (Help to increase the communication among the team members and to make sure they all share the right goals), Planning Meeting (Determine the amount of work that need to be done to provide an incremental release of the product), Review meeting (Help the project stakeholders to review the work done by the team and to decide how to proceed ) and Retrospective (Help the team to achieve a continues improvement).

Continues Delivery

At the end of each iteration (A.K.A: Cycle), the team will deliver an incremental release of the product.

Increased Visibility

The scrum framework provides a great mechanism to allow an increasing visibility of all aspects of the project by using the built-in artifacts such as the Product Backlog, Velocity, and Burndown charts. 

When Scrum is Less Efficient?

There is no doubt that scrum is the leading agile framework used by most organizations, but scrum can still be less efficient in some cases, for example:  

  • The organization does not understand the meaning of the transformation.
  • Regression tests were done manually, which will increase the technical debt.
  • Development teams do not use continues integration (CI) method.
  • The organization does not ready to change its current structure.
  • The organization does not ready to change its culture.
  • There is no framework for an automatic build system.
  • The transition made without the relevant training.
  • There are expectations for instant results. 

Friday, November 24, 2017

Top Agile Myths & Misconceptions | Supreme Agile

Agile software development is probably the most common methodology used by organizations today, as such; many people have started to ask more and more questionד about this methodology that sometimes based on wrong assumptions.

In this article, I will review the most common Myths and Misconceptions that I encounter during agile training courses, hopefully, to help people to divide the truth from the assumptions. 
תמונה קשורה

Myth 1 - Agile is a New Force in the Software Industry

If we compare agile to the traditional methodologies like waterfall we can say that agile is new J, but the truth is that the agile manifesto was created in 2001, and therefore we can say that agile is certainly not new in the software industry.

Myth 2 -  Agile is better than Traditional Methodologies

Although more and more companies are using agile as the preferred methodology, this assumption is wrong! The type of which development methodology should be used should be determined per project and based on the environmental variables. 

For example, we can use the Waterfall methodology in any case that we have clear and informative requirements from day one of the project and stable environment that increase the predictability of the project in a matter of the relevant work that needed to be done.

Myth 3 – There is No Documentation in Agile

This misconception is most likely related to the misunderstanding of the Agile manifesto, where it describes the four principals:

  1. Individuals and interactions over processes and tools.
  2. Working software over comprehensive documentation.
  3. Customer collaboration over contract negotiation.
  4. Responding to change over following a plan.

Now, as you can see there is NO indication that Agile means no documentation or that documentation is not needed, what it says is that the FOCUS should be on delivering a working product instead of investing major time in creating a detailed documentation that may reduce the % of success to deliver the working product. 

There is some basic type of documentation that is very common during each iteration (STD’s, HLD Etc.), the only difference is the number of details and effort put by the team to create them

Myth 4 – Agile Projects are not limited by Deadlines

Similar to traditional methodologies, Agile is not a free ticket to abuse the project timelines, remember that in the end, there is a customer that pays for the software (And a company that needs to earn money…), there is no chance that this customer will agree to work with the company once he been told that there is no expected time for the project completion. 

The main thing in agile is that we can deliver incremental releases of the product in a way that will allow the customer to review the project progress and to use a basic set of functionalities that should be increased per iteration. 

Myth 5 – Agile Revoking the Need for Planning  

In agile, planning is everything! There is no a single project that does not involve a significant planning, the planning is started in the project roadmap, managing the work Prioritization and continues until the team chooses their commitments for the upcoming iteration.

The main difference between Agile and Traditional methodologies is that there is a less upfront planning in agile compared to traditional models that the entire planning is determined at the beginning of the project. In addition, in agile, the planning process performed per iteration (Usually two weeks of work) continually until the end of the project.

Myth 6 – Agile is only suitable for Software projects

The software development community first uses agile techniques and the agile manifesto describes agile in the context of software development. That’s the truth, but Agile is not restricted to software development projects, Think about agile as a framework that we can use to improve the quality and results of a project, this project may be related to software development, Marketing and for almost any project that is based on unpredictable environment. 

Myth 7 – Agile is the Cure for all Problems

Agile will not cure all problems that are part of a Software Development Lifecycle (SDLC), but it will help the organization to enjoy a few major benefits that will increase the % of project success, Examples:

  1. Reduce the Risks.
  2. Increase Visibility.
  3. Better tracking of the project progress.
  4. Better collaboration.
  5. Efficient communication.

Myth 8 – Agile is not suitable to handle large projects

Managing large projects is hard as itself, no matter what is the methodology that you use to manage it, the main difference between Agile and Traditional methodologies, is that in agile we take a large project and break it down to small pieces, which delivered in very short iterations.  

Myth 9 – Agile means No design

The main difference between agile and other traditional models is that in agile we perform design per iteration (Planning meeting) and not in one centralized phase like the one we have in the waterfall model. 

Monday, November 20, 2017

Daily Scrum Meeting - Pitfalls and Negative Patterns | Supreme Agile

תוצאת תמונה עבור ‪Meeting problems‬‏
The daily scrum meetings are the basic platform for the team to discuss and collaborate prior to starting the workday, it’s a daily 15 minutes (MAX) meeting, where the scrum members are asked to provide answers to three simple questions:
  1. What is accomplished since the last daily meeting?
  2. What is your plan for today?
  3. What is keeping you from succeeding to deliver?

Sounds like a very simple meeting agenda, right? However, you will be amazed to see how easy it is to turn a daily meeting into another useless and ineffective meeting.

In this article, I will make a short review of the most common pitfalls and negative patterns that affect the quality of the daily stand-up meeting.   

Mistake #1 - Team Members Not Showing Up On Time

The daily scrum meeting is limited for a MAX of 15 minutes, due to this narrow timeframe, there is a Hugh importance that the participants will arrive on time, although it may look simple to make sure that the team members are attending on time, many teams are still struggling with some of their team members that come late to the meeting due to personal discipline issues.

Suggestions for addressing this issue:
  1. Make sure that the meeting will occur early as possible, but pick the time that is the most comfortable to the team members, getting the team agreement is the first step to guarantee that they will arrive on time (and one less excuse for the team…).
  2. Make sure that there is enough time for the team members between meetings that occur prior the daily and the daily itself, if that the case, make sure that you provide the team members at least 15-20 minutes so they can arrive on time.
  3. Make sure that you do not wait to team members that come late; the rest of the team should not suffer from such behavior.
  4. In case of a team member delay, do not allow them to participate (Feedback is not taken/Given).

Mistake #2 – The Meeting Starts Too Late

The Daily standup is the first meeting that the team has throughout the iteration, as such, it’s a very important to start the meeting early as possible to allow all team members to synchronize and raise any issues that affect their progress.

Mistake #3 –NOT a Status Meeting  

The daily scrum meeting is time-boxed to 15 minutes, if the team members asked to report the work they did on the previous working day, they will most likely start to add technical information that is not relevant to the meeting, as a result, the meeting cannot end at the time scheduled and will become less effective.

The main goal to execute this meeting is to allow the team members to share information and sync about their progress (Based on the three basic questions that you all familiar with), there is no reason to discuss deep technical solutions that encounter the meeting agenda.

Mistake #4 – Too Much Detail

The meeting agenda is relatively simple; the team members are just asked to answer three simple questions, although, in some cases, the answers contains too much information than needed.  If that the case, the other members will lose their attention. To avoid this pitfall, the scrum master should keep the answers short, stop the talking once needed, and take it offline after the meeting. 

Mistake #5 – Keep the Meeting Agenda

To achieve the best results for this meeting, the team should follow the basic agenda of this meeting as it intends to be, one by one, each member of the team will provide an answer to the three basic questions :
  1. What did you do yesterday?
  2. What did you attend to do today?
  3. Any obstacles?

Any further discussion that is not relevant to these questions, should be addressed and resolved (By the SM) after the meeting.  

Mistake #6 – The Scrum Master show

The scrum master “Show” is any situation where the scrum master involvement reduced the effectiveness of the meeting, In many teams there is still a wrong conception that the daily scrum is meant for the scrum master, but this is far from being true, the daily scrum meeting is held for the team to discuss their progress based on the commitments they took at the start of the iteration.

  1. Team members speaking to the scrum master instead of other team members.
  2. While team members are speaking, their eye contact is with the Scrum Master, which will resolve the loss of focus of all the other team members.
  3. The scrum master asks questions while the team members share their answers.
  4. The scrum master starts to plan a technical solution about a work that needed to do.
  5. The scrum master directly asks people to start speaking, the team knows what they supposed to do, so there is no real reason for the SM to interfere.
  6. The scrum master starts issuing instructions to the team members.
To avoid this wrong behavior, it’s the scrum master responsibility to educate the team members about the importance of this items, in addition to that, the scrum master should take one step back (During the meeting) to enforce the team to talk one with each other. 

Mistake #7 – Choose the Right Location

In most cases, the daily scrum meeting held in the team place of work, the main idea behind it is that we want to allow the team to start working as soon as the meeting completes.

Mistake #8 – Working with the Right Tools

Another major failure that can occur during this meeting is when the meeting executed without the relevant tools such as the Task Board and Burndown chart that shows the user stories and their status throughout of the iteration. To avoid this mistake, the meeting should be held with a visible scrum board that will allow the team members to talk about their work with the ability to use the board as a reference. 

Mistake #9 – Mixing of Different Meetings

There are five known meetings in Scrum, each one of them created to address a specific need in the process, in many situations, a common mistake occurs when the team starts to involve goals and process that must be addressed in meetings that specifically designed for that purpose.

  1. The team discusses features that should be developed by the team during the iteration (Should be discussed in the planning and Refrainment meetings).
  2. The team discusses problems that do not relevant to their current commitments (Relevant to the Retrospective Meeting).
  3. The team starts to review their completed work and present it to the other team members (Relevant to the Review meeting).

Mistake #10 - Problem-solving

The third question that is asked during the meeting is “Is there any problem that affecting your ability to work?” a common problem that I frequently see in teams, is that team members and especially the scrum master, are using the meeting time to find a technical solutions for the problems raised instead of keeping the meeting agenda. To handle such problems, The scrum master should write down all issues raised by the team, and addressed them one by one as soon as the meeting completes.  

Saturday, November 11, 2017

Things to Avoid when Writing User Stories | Supreme Agile

תוצאת תמונה עבור ‪user stories‬‏
User stories used in scrum to manage the customer requirements in software development projects, the importance of writing a good user stories is crucial to the success of the projects and therefore they must be written correctly (Small, Informative, Spark conversation  Etc. ) to allow the scrum team to reduce misunderstandings and focusing on delivering value to the customer. 

Writing user stories may seem to be simple but believe me that they are not; there are many ways you can mess it up (Incomplete, inconsistent or missing valuable parts such ass acceptance criteria/DOD), to avoid this common mistakes, I created this list of the most common pitfalls you must avoid while creating your stories.

Large stories that increasing the work effort

Although the agile methodology provides some great process and tools to handle delays and bottlenecks that may arise during the iteration (Move it to the next iteration, rework and modify the story Etc.), we want avoid this scenarios by creating stories that will allow the team to take commitments that based on short units of work. Stories that created with the original scope that determined by the team during the planning meeting and modified during the iteration may increase the scope of the story in a way that will reduce the percentage of the team to meet their original commitments.

Stories that are changed throughout the iteration are more than welcome, this is agile all about (We embrace changes in requirements to satisfy the exact needs of the customer). However, there is a way to handle these requirements by splitting the original story into two (or more) stories that will allow the team to focus on their original commitments and then handling the new stories. 

Lack of Visibility

Stories that are not visible to the relevant stakeholders can lead to many problems such a lack of communication, failure to understand the “Big” picture and most importantly the ability to make an efficient prioritization.

Technical tasks that were written as user stories

There is a reason that user stories containing tasks and no the opposites, tasks should not be added to the product backlog in a makeup of user stories; this pitfall is mainly relevant to new teams that are not familiar with the different artifacts of Scrum.

 As a result, the team members add technical tasks as user stories, which may lead to confusion among the stakeholders once they need to prioritize the product backlog or determine which stories will be added to the next iteration.

The business value is not taking into consideration

We should always remember that the importance of the user story is mainly based on the value that it adds to the customer if the user story is written without the product owner really understand the business value that this story will add to the client, how can he make a real and effective prioritization process? To be able to make an effective prioritization process, the product owner must understand the business value of each user story and why it was originally requested by the customer. 

Stories that were written without collaboration

Collaboration among the relevant stakeholders is the main key to succeeding at writing great stories. Both the product owner and the team (Developers, Testers Etc.) should all collaborate prior to wring a user story. But making this collaboration, each role can contribute his own knowledge and experience that will most likely help to create improved and efficient stories.

Stories that do not provide answers

To write a great user story, the creator should provide answers to some basic questions:
  1. What should the team develop to meet the customer request?
  2. What is the business value of this story?
  3. What is the acceptance criteria that the team members should follow prior to starting the story?
  4. What is the Definition of Done that the team should accomplish prior to them to mark the story as “Done”?
Failure to provide answers to those basic questions will lead to confusions that will affect both the quality of the team deliverables and commitments.

My Presentations