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

Risks in Programs and Porfolios

Business Justification Techniques in Scrum

Scrum and Kanban Boards

Minimizing Risks Through Scrum

Agile Planning Essentials

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 (10)

We are ready for any unforeseen event that may or may not occur.

- Dan Quayle