Agile Thoughts

This blog represents everything agile. Agile thoughts, issues, concerns, experiences, etc. I want to share and provide an outlet for the agile mindset. "Don't just do agile, be agile".

About this Blog


Recent Posts

Implementing Programs in Scrum

Regression Testing in Scrum

Planning for Uncertainty

Task Estimation with Scrum

Scrum Guidance Body Recommendations

Metrics and Measuring Techniques in the Retrospective Meeting

A retrospective is a time-boxed ceremony where the Core Scrum Team (optional for the Product Owner) convenes to discuss the iteration that was most recently completed. This practice is very similar to the lessons learned meeting that takes place in waterfall projects. Pertinent information is collected during these meetings and is documented for utilization in future Sprints. Scrum Team members discuss their existing best practices, potential improvements, issues and blockages. The Scrum Master ensures that the high priority recommendations are implemented not later than the next Sprint.

The retrospective is an Inspect and Adapt event that is facilitated by the Scrum Master. Discussions, based on what went right and what went wrong, are recorded for imminent accomplishment. Participation by all team members is expected. The main goals of the retrospective are to provide responses for three distinct assessments:

  1. What are the things that the Scrum team needs to continue doing?
  2. What are the things that the Scrum team needs to start doing?
  3. What are the things that the Scrum team need to stop doing?

Metrics and Measuring Techniques

There are a variety of metrics that a Scrum team can utilize to measure their performance on a Sprint by Sprint basis. These metrics have been identified in Table 1. below.



  1. Velocity

The number of story points completed in a specific Sprint.


  1. Completed Success Rate

The percentage of story points that have been completed compared to the commitment made by the team.


  1. Estimation Accuracy

The number or percentage of variations between projected and actual time spent on tasks and user stories.


  1. Feedback Ratings

The feedback obtained from stakeholders using subjective or objective ratings and providing a measurement of team performance.


  1. Team Morale Ratings

The outcomes from self-assessments concerning team member morale levels.


  1. Peer Feedback

The methods used to obtain constructive feedback to provide understanding about team performance.


  1. Release Progress

The business value provided in each release that increases the motivation levels of the team and work satisfaction.


Table 1. Retrospective Metrics


Velocity is a number that stands for the average number of user stories that have been completed during the Sprints. When a Scrum team has determined the average number of story points that they can complete, they can then calculate the estimated time frame that it will take to finish the project. The team will use the number of user stories that need to be completed and then divide this number among the remaining Sprints. For example, if a team has a total of 150 story points remaining, then the projection for completion is then 9. This assumes that the average velocity has been averaged at 17 story points per Sprint.


  • Team A has completed the following number of story points during the Sprints:
    • Sprint 1 – 15 story points
    • Sprint 2 – 16 story points
    • Sprint 3 – 20 story points
    • Average of Sprints 1,2,3 = 15+16+20 = 51/3 = 17 is the velocity
  • Story Points Remaining / Velocity = Number of Iterations Remaining
  • 150/17 = 8.82 = 9
  • It will take 9 Sprints to complete 150 story points based on the team’s projected velocity of 8.82


Completed Success Rate

This metric is represented as a percentage of the story points completed based on what the team projected that they would complete. For example, if the team made a commitment to complete 50 story points and they only completed 49, the completed success rate would be 49/50 = 98%.


Estimation Accuracy

This metric is represented as a percentage of the actual time spent on tasks and user stories and the time that the team estimated would be needed. For example, if the team estimated their total work as 50 hours and it took 45 hours to complete, then 45/50 = 90% estimation accuracy.


Feedback Ratings

This metric is the feedback rating from the stakeholders on the project using subjective and/or objective ratings that measures the Scrum Team’s performance. For example, stakeholder may provide feedback as “Very Good, Excellent, or Outstanding”.  This would be an subjective measurement of feedback. On the other hand, if a stakeholder responds on a scale of 1 to 5, where:

  • 1 = Outstanding (A)
  • 2 = Very Good (B)
  • 3 = Good (C)
  • 4 = Fair (D)
  • 5 = Poor (F)

The above measurement represents an objective feedback rating.


Team Morale Ratings

The Scrum Team members conduct self-assessments regarding their morale in relationship to the project. For example, team members provide information such as:

  • Team Member 1 morale = High
  • Team Member 2 morale = Low
  • Team Member 3 morale = High


Peer Feedback

This metric is used to provide feedback for Scrum team members where each team member choses a peer, conducts observation during an agreed upon time frame and then share the information to the selected peer. With Scrum, other members of the Core Scrum Team can participate in peer feedback (Scrum Master, Product Owner). Some firms use the 360-degree feedback model, a many-to-many feedback format. This model focuses on team member performance evaluation and a questionnaire is typically used. This model has little to no team collaboration.


Release Progress

This metric is based on the amount of business value that is provided in each release based on story points. A Release Burnup Chart is used to identify the work completed for the release. A business uses this metric to determine how much work has been delivered. Burndown Charts can also be used for this metric. See Figure 1. below.


Figure 1. Release Burnup Chart (Agile Velocity Blog, 2014)

In conclusion, companies have their organizational specific measurement techniques and metrics. The metrics presented here are just examples used during the Retrospective meetings and the choice of which ones to use are based on the project’s needs.

Keywords: retrospective, metrics, measurements



Agile Alliance. (2015). Glossary. Velocity. Retrieved from

Agile Alliance. (2015). Peer Feedback. Retrieved from

Agile Velocity Blog. (2014). Improve Your Visibility into Release Progress. Retrieved from

SCRUMstudy. (2016). A Guide to the Scrum Body of Knowledge (SBOKTM Guide.), 3rd Edition

Posted on: September 09, 2018 12:12 AM | Permalink | Comments (9)

Impediment Logs in Scrum

Categories: Agile, Impediments, Scrum

Impediments are barricades, hurdles or obstacles. In terms of Scrum, they are “blockers” that prevent the Scrum Team from completing work, which in return impacts velocity. Anything that prohibits the team from doing work is considered an impediment. Examples of Scrum impediments are listed in Table 1.

Impediment Types

  • Sick Scrum Team member
  • Slow Agile/Scrum adoption
  • Too cold team room
  • Process issues
  • Business or customer issues
  • Cultural or waterfall issues
  • People issues
  • Blockers for a User Story
  • Unresolved dependencies
  • Faulty equipment

Table 1. Scrum Impediments

The Scrum Master is responsible for tracking, monitoring and ensuring that impediments are removed. All Scrum Team members are responsible for continually identifying impediments for discussion during the Daily Standup Meeting. If for some reason an impediment does not disappear in a timely manner, this would indicate that the root causes have not been identified. The Sprint Retrospective is another place for impediments that reoccur. It is important to understand that the Scrum Master is not solely responsible for the removal of impediments. The team should work together to remove impediments that can be easily resolved and provide assistance with any additional support that may be required.

A few things to note:

  • Impediments that are identified daily are generally very small and can be quickly resolved. This may include sending a simplifying email and/or getting assistance from a Scrum Team member.
  • The bigger impediments are most likely to be identified during the Retrospective meetings and require a level of dedication to be removed. These types of impediments are added to the Sprints for resolution.
  • Impediments that are identified by the team are added to the Product Backlog for prioritization and processing. Large items that are not able to be addressed quickly are addressed in later Sprints.
  • Organizational impediments added to the Impediments Log are prioritized and addressed on an ongoing basis. Both team and organizational impediments are reviewed after each Sprint in the Retrospective meeting.

There are two main types of impediments, organizational and team related and they need different types of handling.

  • Team Impediments – issues that the team can solve without needing external assistance. However, the team may need internal assistance from management. These types of impediments would include but are not limited to:
    • Changes to the way that the team works
    • Reminders for when a specific problem re-occurs
    • The need for tools or workflows that can make team’s work easier
    • Internal measures put in place for the team to avoid repeating a prior error
  • Organizational Impediments – issues that are dependent on others to solve. These issues include but are not limited to:
    • Slow internet
    • Issues with obtaining input from other teams or divisions
    • Lack of training

The expectation is that the team can learn to remove its own impediments without the Scrum Master’s intervention. This also means that impediments in the log should not be delegated to the team because many of them may be very difficult to resolve. On the other hand, the Scrum Master is not expected to resolve all impediments alone either. The entire Scrum Team needs to work together to determine which impediments it can resolve and what support may be needed. Over time, the team should become capable of removing more and more impediments on its own.

Impediment Logs

There should only be a single Impediment Log for a Scrum Master to manage. Table 2. outlines the process that is typically used to create, monitor and maintain the Impediments Log.



  1. Record

The Daily Standup Meeting is the best time to document impediments in the Impediments Log as each team member reveals them. After the brief meeting, the Scrum Master will gather additional information so that the impediments can be prioritized.


  1. Prioritize

Impediments should be prioritized based on their levels of importance and in relation to those on that are already on the log.


  1. Publish

The Impediments Log should be made visible to everyone and posted for all to view.


  1. Address

The Scrum Master should address the highest priority impediments from the log and ensure that it is removed so that the team can continue to reach the Sprint’s objective.


  1. Communicate

When the impediment is removed, this information should be communicated to the involved parties and the Impediments Log is updated.


Table 2. Impediments Process in Scrum

Table 3. identifies a description of each of the field on the Log. Figure 1. is an illustration of an Impediments Log. Let’s examine the data input fields to gain the proper understanding of their usage.

Impediments Log Field


  1. Impediment Description
  • Identifies what the impediment is


  1. Importance of Impediment Resolution


  • (Blocker, Critical, Major, Minor), Describes the priority level


  1. Action suggested to be taken


  • Recommended action to be taken to resolve the impediment


  1. Owner
  • The person assigned to remove the impediment
  1. Due date of when it must be resolved


  • Deadline date for resolution
  1. Release that impediment was identified in
  • Release number


Table 3. Impediment Log Data Input Fields

Figure 1. Impediments Log

Tips for Removing Impediments

Following are several tips for the removal of impediments:

  • Impediments should be identified at any time. The Scrum Team should never wait until the Daily Scrum to discuss them.
  • If an item will prevent the team from achieving the Sprint Goals, it’s an impediment.
  • There is a distinct difference between blockers and impediments. A blocker impacts a single task and an impediment hinders overall progress.
  • Use an Impediments Board to ensure of adequate transparency. This means that Impediments should be included in the list of Information Radiators.
  • Track completed impediments. This information is good feedback for the Sprint Review and Retrospective meetings.
  • The Scrum Master needs to understand the organizational culture to best figure out how to remove impediments.
  • Use courage and creativity to remove impediments. Ask for forgiveness later if a bold decision needs to be made.
  • Collaborate with the Product Owner. Many impediments in Scrum are related to product management, stakeholder and supplier collaboration.
  • Don’t waste time and effort in fixing incorrect problem. Make sure that the focus is on the real problem(s).

Keywords: Impediments, Logs, Scrum


CoreWorks. (2014). The Impediments Backlog. Retrieved from

Getting Agile. (2011). Organizational Impediment Management: Early Risk Detection for Agile. Retrieved from

LeanAgileTraining. (2017). What are Impediments? Retrieved from

Openbravo wiki.  (2009). Scrum/Impediment. Retrieved from

Overeem, Barry. (2016). The Scrum Master as an Impediment Remover. Retrieved from

Scrum Alliance. (2011). Five Tips for Impediment Resolution With Scrum. Retrieved from

scruminc. (2017). Impediments. Retrieved from

Posted on: September 08, 2018 11:57 PM | Permalink | Comments (10)

Agile Planning Essentials

Agile Planning involves quantifying the pace that a team can develop user stories into working software. The team’s velocity is the measurement of its throughput which is used to establish expectations regarding future delivery dates. To establish delivery dates, we examine the total amount of work for the project and divide it by the established team velocity. We then gauge how many iterations are needed to deliver the entire project. For example, if we have 100 story points to complete the project and the team’s velocity is estimated at 15 points per iteration, we calculate the number of iterations needed as follows:

  • Total Effort/Estimated Team Velocity = Number of Iterations
  • 100/15 = 6.66 = 7 iterations

As the team begins the Sprints, there are two things that can occur.

  1. The team will deliver faster than projected
  2. The team will deliver slower than expected

Release Planning

Release Planning involves a commitment to plan the delivery of a product increment of value. The Scrum team is responsible for planning the releases. Table 1 describes the responsibility of the team during this ceremony.





  • Scrum Master
  • Facilitator for the Release Planning meeting
  • Product Owner
  • Outlines the contents of the Product Backlog
  • Delivery Team/Agile Team
  • Discusses technical feasibility and dependencies
  • Stakeholders
  • Trusted Advisors for decisions made about the release plan



Table 1. Release Planning Roles and Responsibilities

What Happens Before the Release Meeting?

Prior to the start of the Release Planning meeting, the Product Owner needs to ensure that the Product Backlog has been prioritized. The Scrum Team should provide input about capabilities, velocity and any technical impacts. The vision statement, market and business objectives should be established. The Product Owner, if applicable, needs to announce whether new product backlog items will be needed.

Release Planning Data and Output

In terms of needed data for the Release Planning meeting, data from previous Sprints and releases would be beneficial. Stakeholders typically, but not always, provide feedback about the product, market conditions and proposed deadlines. Also useful are Action Plans and goals from previous releases and retrospectives. There may be additional items and unresolved defects that should be revisited. The team should be on hand to discuss the relevant development and architectural information. In addition, the team’s estimated velocity based on previous iterations should be considered as well as input from other technical team and subject matter experts to properly manage dependencies. The output from Release Planning includes but is not limited to the following:

  • Release Plan
  • Team Commitment to the Plan
  • Suggestions for improvement regarding future Release Planning meetings
  • New user stories for the Release Backlog

The Sprint Planning

Every Sprint starts with a Sprint Planning meeting. All team members should be present because this is the chance to determine how much work can be completed in the upcoming Sprint. The Guide to the Scrum Body of Knowledge (SBOK Guide) suggests that a one-month Sprint Planning Meeting has two parts and is time-boxed to eight hours:

  1. Objective Definition – This event occurs during the first half of the meeting where the Product Owner discusses the highest priority User Stories in the Prioritized Product Backlog to the team. The Scrum Team then defines the Sprint Goal.
  2. Task Estimation – This event occurs during the second half of the meeting where the Scrum Team determines how to finish the work in the Sprint Backlog to meeting the Sprint Goal.

The User Stories are estimated, approved and committed. Each Scrum Team members participate in an estimation of the tasks using common techniques such as Planning Poker. In the case of where the estimating is lengthy, it would mean that the team was not totally prepared to start the Sprint. Effort Estimation is used to select the tasks that are needed to complete the work. The Sprint Backlog is created as well as the establishment of the Burndown Chart and the team commitment is made verbally.

There are two events that should not occur during a Sprint Planning meeting:

  1. Grooming – The refinement of the User Stories that should be done prior to the Sprint Planning Meeting.
  2. Updates or Revisions – The User Stories should be clearly defined and ready to be broken down into tasks and then estimated. Updates to the User Stories should not occur during Sprint Planning.

Iterations Length

According to the rules of Scrum, the length of an iteration should not be longer than four weeks. The length of the Sprint is the determining reason as to how fast the Scrum team can inspect and adapt to fluctuating situations and continuing to learn. By having a maximum length for the Sprint, the Scrum Team is practically guaranteed a minimum benefit.  If a Sprint is longer than four weeks, the benefits of Scrum are lessened. Risks have the potential to be increased because of short-term planning, adapting to change, the development of the team, detection of errors and the timing of business opportunities.

Task Estimates to Story Points

Story Points represent a high-level estimation of complexity that is used prior to Sprint Planning. Story Points and velocity are relative measures that provide agreed upon guidelines about the user stories that will be committed in the iterations. On the other hand, task estimates based on hours are very low-level estimates that are used to represent the specific effort in hours that will be required to complete the User Stories during a Sprint. Tasks estimates should be as accurate as possible whereas Story Points are never expected to be exact. Since story points and task hours are used for very different purposes for different situations, the attempt to make a correlation between the two is not recommended. Figure 1 outlines when to use Story Points and Task Hours.

Figure 1. Story Points and Task Hours


Agile Advice by Berteig. (2013). The Rules of Scrum: Every Sprint is Four Weeks or Less in Duration. Retrieved from

Agile in a Nutshell. (2016). (n.d.). Planning. The Fine Art of Expectation Setting. Retrieved from

CA Technologies. (2017). Release Planning. Retrieved from

Scrum Alliance. (2012). Story Points Versus Task Hours. Retrieved from

SCRUMstudy. (2016). A Guide to the Scrum Body of Knowledge (SBOKTM Guide.), 3rd Edition

SCRUMstudy. (2017). What Happens at a Sprint Planning Meeting? Retrieved from

Posted on: January 16, 2018 07:33 PM | Permalink | Comments (13)

Agile Leadership

Categories: Agile, Leadership

With Agile Methods, leadership styles are diverse and based on organizational specific environments, goals and the human resources on the Scrum project. While many of us are fully aware of the term Servant Leadership, there are other leadership styles that are also relevant. A discussion follows on the variations of common agile leadership styles that are used with Agile Methods.


Servant Leadership


To no surprise, the preferred leadership style for Agile projects is Servant Leadership. With this style of leadership, serving others comes first and foremost. The expectation is that one needs to instinctively have a sentiment of wanting to serve first. The next mindful choice is the desire to lead others. The servant-leader is very different from the person that is a leader-first because that specific need is based on the attainment of power. The leader-first and the servant-first are two very different types where one is strictly focused on ensuring that other people’s needs are being served, first before their own. The servant-leader is an organizer that realizes results by focusing on the needs of the Scrum Team. This is the preferred style of leadership for a Scrum team.


Unbeknown to many, the concept of servant-leadership started years go by Robert K. Greenleaf in the year 1970. Greenleaf published an essay entitled “The Servant as Leader”. He described the servant-leader as having a strong desire to help others. This person identifies ways to meet the needs of customers, communities and teammates. This type of leader encourages ethical reasoning among those that are followers. The servant-leader typically develops long-term relationships with followers and they encourage their personal development so that they can obtain their full potential. The concerns of the servant-leader are the achievements of all stakeholders; not just a select few.


A Servant-Leader uses their abilities of listening, compassion, dedication and perception when working as a Scrum Master or Product Owner for the Scrum Team. This role shares their authority and influence with the team. The Scrum framework identifies the Product Owner and the Scrum Master as the servant-leaders of the Scrum team. To be successful, the servant-leader should possess the following skills:




  1. Listening

The servant-leader should listen closely to what is said and what is not said by the Scrum team members and stakeholders. They need to understand others by getting in touch with their inner selves and reflecting on their own feelings.


  1. Empathy

The servant leader acknowledges people for their skills and capabilities. The assumption is that people, specifically the Scrum team members, are sincere.  People are accepted as individuals even under the scrutiny of social or work-related issues.


  1. Healing

Servant-leaders are great motivators that are self-healers and they use this skills for healing Scrum team members’ relationships with others. They are understanding and take on the responsibility of helping their colleagues who are going through emotional dilemmas.


  1. Awareness

Being aware and specifically, self-awareness is a strength of the servant-leader. This trait permits them to understand and incorporate concerns that pertain to ethics, authority and beliefs.


  1. Persuasion

A servant-leader is persuasive, as opposed to using their role and authority to gain agreement and influence decision making among the Scrum team members. They never force or coerce the team because they always resort to friendly persuasion.


  1. Conceptualization

This role can visualize and evaluate problems on a theoretical and futurist perspective as opposed to focusing on near short-term objectives.


  1. Foresight

The servant-leader has an instinctual mind that permits them to make use of and apply lessons learned and existing truths to forecast outcomes of present situations and conclusions.


  1. Stewardship

The servant-leader is committed to serving others by using persuasion rather than control to gain the trust of Scrum team members and others in the organization.


  1. Commitment to the growth of others

Those that are servant-leaders are committed to the growth of individuals in the organization. They take responsibility for nurturing others in terms of personal, professional and spiritual growth. The servant-leader ensures that access is provided to resources that enhance the development of others. Teams are also encouraged to engage in the decision-making process.


  1. Building Community

Servant leaders are interested in building communities within a working environment, primarily because of the focus in society toward large institutions that shape and control human lives.


Table 1: Servant-Leader Desired Skills


There are additional agile leadership styles that may be not so familiar as the servant-leadership style of agile management. They include but are not limited to the following:


Leadership Style


  1. Delegating

Leaders that delegate are included in most of the decision making, and only a few selected planning and decision-making tasks are delegated to team members based on their levels of competency. This style of leadership is proper in cases where leaders are in sync with the project specifications and time frames have limitations.


  1. Autocratic

An autocratic leader makes their own decisions without any team member involvement in discussions before decisions are made. This is not a recommended style of leadership and it should only be used in exceptional situations.


  1. Directing

This leadership type directs team members regarding which tasks are needed, when they should be done and how they should be accomplished.


  1. Laissez Faire

This leadership style leaves the team without supervision most of the time. The leader does not interfere with daily work activities. Many times, this style results in a state of chaos.


  1. Supportive Coaching

Supportive and coaching leaders provide direction and support. They then monitor the team by means of listening, providing assistance, encouraging and having a positive outlook during indecisive times.


  1. Task-Oriented

The task-oriented leader imposes the completion of tasks and the meeting of deadlines.


  1. Assertive

The assertive leader addresses concerns and shows confidence when establishing authority with respect.


Table 2: Leadership Styles



Keywords: leadership, styles, agile



SCRUMstudy. (2016). A Guide to the Scrum Body of Knowledge (SBOKTM Guide.), 3rd Edition

Keith, Kent M. (2017). To Serve First. The Servant Leadership Journey. Retrieved from


Posted on: December 05, 2017 04:02 PM | Permalink | Comments (11)

"In three words I can sum up everything I've learned about life. It goes on."

- Robert Frost