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

Risks in Programs and Porfolios

Categories: Portfolios, Programs, Risks

Risk identification at the program and portfolio levels can be an extremely challenging activity. The main thought process about risk management at these levels is to share ownership at the project level with those at the program and portfolio levels. Probability and impact ratings vary at different levels and risk rarely occurs at a single level without affecting higher levels. When risk is identified at multiple levels, this constitutes a very high level of risk management complexity. 

Program Risk Management 

Risk at the program level include threats that are often present at the project level. Typically, risks are present in both existing and successive projects within a program. Quite often, these risks can be mitigated early with the same actions across a program. Program risks have the potential to have a cascading effect on projects within a program, resulting in more effort to resolve.  

A common viewpoint of the program manager is that a single project’s contribution has a very limited impact at the program level. The program manager often feels that the resolution to project related risk that impacts a program is best resolved by termination. In the case of a risky but critical project in a program, removal is not an option. Projects within a program have different levels of criticality and the overall level of acceptable risk is based on the organization’s risk tolerance level. 

Portfolio Risk Management 

Most companies measure risk from within an enterprise portfolio. Every program must examine each project to determine if the risk level is within an acceptable range. High risk often results in high returns and the lower the risk, the lower the expected return. It is important to create a balance of high and low risk projects and programs to provide the maximum amount of return. Effective risk management should be developed to incorporate and provide protection for the entire organization.  

Risk management at the portfolio level starts at the upper management level and should include all stakeholders. The process begins by taking an inventory of the ongoing projects. Leaders in the organization should define goals in terms of what should be accomplished. A predictable measure for risk at the portfolio level should be defined. Risks are categorized based on possible outcomes, impact and probability of occurrence. Many organizations use portfolio risk management software because it offers a framework for the establishment of communication requirements. Such tools are known to create a leveled playing field that excludes personalities, politics and favored projects.  

After the identification of portfolio risks, mitigation activities must be defined. Executives in the organization reviews all initiatives for elimination after the risk analysis process. The remaining group of initiatives for consideration are re-evaluated and re-prioritized with their mitigation strategies. The executive leaders will select the initiatives that will grow the company in the proper direction. Initiatives are then decomposed into projects. This begins the lifecycle of corporate initiatives and related projects. The takeaway from risk management at the portfolio level is that organizational cultures must value risk. In real life, change will undoubtedly occur and risk and opportunities can come to fruition quickly. It is beneficial for an organization to establish risk management at the enterprise level because of the following benefits:  

  • Communication and participation is improved for all stakeholders 

  • Improvements in corporate processes that propose and approve investments 

  • Process transparency and consistency results in faster organizational consensus 

  • Prioritization of investments provide savings based on the portfolio’s merit 

  • Timely identification of programs and projects at risk 

  • Release of funding needed to invest in new initiatives for business transformations 

  • Lessons learned that add value to consistent refinement of the portfolio management process 

  • Project management balance that optimizes business value for the entire portfolio 

Agile Risk Management 

On agile projects, all team members are responsible for the identification of risks that have the potential to impact development sprints, projects or programs. Scrum ceremonies provide the venue for risk identification on a regular basis. Risks are identified during the following Scrum encounters: 

  • Daily Scrum  

  • The main forum for risk and issue identification daily 

  • Retrospectives  

  • Risks can be uncovered during continuous improvement discussions 

  • Requirements Analysis  

  • The Product Owners leads requirement discussions for the purposes of maximining value and minimizing risks 

  • Sprint Planning 

  • During this meeting, the team identifies, evaluates and provides risk responses for identified risk 

  • Sprint Review 

  • Stakeholders are kept in the “know” and risk mitigation activities are discussed 

  • Scrum of Scrums 

  • Risks and issues are addressed at the team, project and program levels 

  • Planning Poker 

  • Story size estimation occurs and provides the opportunity for risk reduction by eliminating user stories that are too large and need to be broken down 

Figure 1. below outlines the Agile Risk Management process (Identify, Assess, Respond, Review). 


Figure 1. Agile Risk Management Process (Yegi, 2015) 

There are four ways to address risk in agile environments: 

  1. Mitigate – An agile team implements risk mitigation by focusing on their velocity or capacity to develop the features tied to the user stories. They agree to the amount of work that they feel confident can be completed and nothing more. 

  1. Avoid – Projects or components of a project are cancelled to avoid threats in their entirety. The product owner will remove or change stories to eliminate this type of risk. 

  1. Contain – The agile team agrees to just “deal with” the low impact and probability risk when it occurs. 

  1. Evade – No risk action is taken when it is evaded. This typically pertains to risks that have been determined to have very little impact on the objectives of the project. 

Risk management at any level adds value to the organization and this ultimately impacts profitability. Leaders can proactively manage expected variances in programs and portfolios with adequate risk mitigation strategies.  

Keywords: Risk, Programs, Portfolios 


Faris, R. K. & Patterson, D. (2007). Managing risk in the project portfolio. Paper presented at PMI® Global Congress 2007—North America, Atlanta, GA. Newtown Square, PA: Project Management Institute. Retrieved from 

Wideman, Max. (2015). How do Project Risks Impact Programs & Portfolios? Retrieved from 

Yegi, Sanni Babu. (2014). Risk and Issue Management in the Scrum Process. Retrieved from 

Posted on: May 08, 2018 01:08 PM | Permalink | Comments (4)

Business Justification Techniques in Scrum

All projects are usually required to undertake a business justification process, and Scrum is not an exception. This practice is essential because it helps the business understand its options pertaining to change initiatives, new products or services and providing justification for undertaking a new project. The business justification process is also an enabler for the Product Owner to start the creation of the Prioritized Product Backlog for meeting the expectations of executives and shareholders.

The Importance of Business Justification

It is important to conduct the business justification process because the reasons why a project should be undertaken must be clear and factual. The justification for the project must be established prior to approval. It must be demonstrated that the project is viable and the justification process is the driver for all project evaluations. A business should never expend large amounts of funding at the beginning stage or for the project continued until the justification process has been conducted. To be clear, the business justification process should be implemented on a continuous basis; at the beginning, at established intervals throughout the project lifecycle and whenever a risk or issue presents itself. Table 1 outlines the factors that drive the business justification process.





  1. Project Analysis

All factors that justify the project, both good and bad, and selected or not. For example, low profits, legal issues, etc.


  1. Business Needs

Business needs that will be fulfilled by the project. These needs should be included in the Project Vision Statement.


  1. Project Benefits

All quantifiable improvements in the project’s result, service or product that can be provided after completion.


  1. Opportunity Cost

The costs for the next business opportunity or project that was disregarded because of the selected project.


  1. Major Risks

Uncertainty or unplanned events that have the potential to affect the success or achievability of the project.


  1. Project Timeline

The duration of a project and the timeframe that the benefits are realized.


  1. Project Costs

Investment and other development costs for the project.


Table 1: Business Justification Factors

The Business Justification Process

This justification process commences prior to the initiation of a project and is consistently validated throughout the lifecycle. Business justification is determined by means of the following three steps:

  1. Present and Evaluate a Business Case - A project is generally evaluated and approved by the Product Owner. After approval, the project is documented and presented as a business case. Subsequently, the Product Owner creates a Project Vision Statement and obtains approval from executives and/or the project or program management board.


  1. Justification of Continuous Value - After decision makers have approved the Project Vision Statement, it is baselined and delineates the business justification. The business rationalization is continuously validated during the entire project execution stage and at predefined milestones. During the project, the Product Owner should regularly make certain that the Project Vision Statement is updated with the appropriate information to reliably empower decision makers to continue to make up-to-date decisions.


  1. Benefits Realization Confirmation – The Product Owner has the responsibility to confirm the realization of customer benefits throughout the project and when the User Stories in the Prioritized Product Backlog have been developed and accepted.

Business Justification Contributors

The Product Owner is held being accountable for directing the activities that substantiate and keep track of business value for their assigned projects, programs or portfolios. In addition to the Product Owner, there are additional parties that provide contributions to the fulfillment of business justification activities such as:

  • The Sponsor – provides the required funding for the project and monitors the project to validate the realization of its benefits


  • Customers and Users – participates in defining the prioritized list of requirements and User Stories in the Prioritized Product Backlog. They also review product deliverables during each Sprint and Release and provide confirmation that benefits have been realized.


  • The Scrum Guidance Body – possibly provide recommendations and guidelines that pertain to business justification techniques and the confirmation of benefits realization.


  • The Scrum Master – facilitates the development of the project’s deliverables, manages risks and changes, and removes impediments. Collaborates with the Scrum Team, Product Owner and stakeholders to ensure that project benefits are realized.


  • The Scrum Team – completes the deliverables for the project and contributes to the realization of business value.

Business Justification Calculations

There are many tools that can be used to evaluate and review projects during the business justification process. We focus our discussion on calculating the Project Value Estimation. Expected business value can be estimated using several methods such as Return on Investment (ROI), Net Present Value (NPV) and the Internal Rate of Return (IRR). Following is a synopsis of these three methods.

  1. Return on Investment (ROI) – This calculation is used to justify a project by assessing the expected net income to be returned from a project after deducting the costs and then dividing by the total project cost. Using ROI, project value is calculated with the following formula:


  1. ROI = (Project Revenue – Project Cost)/Project Cost
  2. Example: With a project cost $2,000,000 to develop, expected financial benefits estimated at $5,000,000, ROI is determined as follows:
  3. ROI = ($5,000,000 - $2,000,000) / $2,000,000) = 1.5
  4. ROI is 1.5 times the initial investment (or 150%)


  1. Net Present Value (NPV) – This calculation is used to figure out the current net value of future benefits with a presumed interest rate. NPV is the total expected income from a project minus the total cost of the project, considering the time-value of money.
    1. We are trying to decide between two projects:
    2. Project 1 has an NPV of $8,000 and its life cycle is 5 years
    3. Project 2 has a NPV of $5,000 and its life cycle is 2 years
    4. Project 1 has a higher NPV and we are considering the present value and NOT the future value.


  1. Internal Rate of Return (IRR) – This calculation is a discount rate on the investment where the present value of cash inflows is made equivalent to the present value of cash outflows for determining a project’s rate of return.
    1. We are trying to decide between two projects to take on.
    2. Project 3 has an IRR of 5% and will be done in 4 years
    3. Project 4 has an IRR of 15% and will be done in 2 years
    4. Project 4 is the right one to select because it has a higher IRR and the duration is not being considered because time has already been considered


Keywords: justification, scrum, business



Investopedia. (n.d.). Payback Rule. Retrieved from


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

Posted on: April 04, 2018 08:28 PM | Permalink | Comments (8)

Scrum and Kanban Boards

Categories: Scrum

The Scrum Board is an important component of the Scrum methodology. This board is used by Agile teams to track their development work within time-boxed iterations called Sprints. The Scrum Board shows all backlog items that need to be completed within the current Sprint. Team members use the board by completing work and making updates continuously throughout each Sprint. Scrum team members typically make updates to the board daily because of progress made the previous day. The board’s layout consists of rows and columns, where each row contains user stories (units of work), and columns that show the status. Scrum boards provide a fast, simple view of the user stories selected for a Sprint that the development team is working on and have been completed. Figure 1. shows a typical Scrum Task Board used by the Scrum team.

Figure 1. Scrum Task Board

Every row on the Scrum board contains user stories that represent product backlog items that have been selected during Sprint Planning. Following is a description of the columns on the board:

  • The “Story” column identifies the user story that is ready to be worked on by the development team.
  • The “To Do” column represents tasks that need to be completed.
  • The “Work in Process” column represents tasks that are currently being worked on.
  • The “To Verify” column represents tasks that need to be verified and tested.
  • The “Done” column represents completed tasks.

The Kanban Board

The Scrum board, as well as the Kanban board, is used to show the progress of development work. Both boards are categorized as whiteboards in the “To Do-In Progress-Done” categories. The Kanban board is used to display the work process flow and the number of items in the work in progress (WIP) column. According to Lean concepts, WIP should be limited to where it is small enough to avoid wasteful tasks, but large enough to reduce the number of idle workers. In terms of WIP limits, the following applies:

  • Scrum limits WIP per Sprint. The Scrum team can have unlimited items in the “In Progress” column.
  • Kanban limits WIP per workflow status (Ready, Kick-Off, In Progress, Review, Accepted). A number in the “status” sections means that the maximum number of items cannot be greater than that number. Figure 2. Shows an example of limits on the Kanban board. Observe that the Kick-Off Column has 1 as its limit, In Progress has a 3, and Review has a 2.

Figure 2. Kanban Board with WIP Limits

Kanban vs. Scrum Board

With a Scrum board, the entire team is responsible for each task. With the Kanban board, the team is not responsible, but each person has responsibility for their step on the task flow (development, testing, verifying, etc.). If a team member has completed their task, that person can choose what to do by either helping another team member with their taskings or take on another activity from the queue. A Scrum board is used by one Scrum team whereas the Kanban board is a workflow that is not required to be owned by a specific team. The Product Owner should not be able to make changes to a Scrum board because of the team’s commitment to complete a specific number of user stories. The Scrum team members are the only parties that can make changes to the Scrum board. With Kanban, the Product Owner (or proxy such as Service Delivery Manager) can edit the Kanban board. The Scrum team should not add any new items to the Scrum board during a Sprint. Work items are set in stone during Sprint Planning before iterations begin. Kanban has no established time frame for making updates to its board because it has limits on the work in progress activities. When tasks are moved from the In-Progress column to the Done section, capacity is released and new work items goes to the Development queue.

Team Utilization                  

In some cases, an Agile team may decide to add additional categories to their Scrum Boards that match their actual workflows. Most boards have a minimum of three categories: To Do, Work in Progress, and Done. The optional categories may be, for example, Testing or Verify columns. A virtual Scrum Board adds a lot of value to Product Owners and Scrum Masters can create metrics that help improve the Scrum team’s processes. Often, teams use a combination of physical and virtual boards to the relevant advantages of both. Additional categories that are used on Scrum boards include but are not limited to the following:

  • New Features
  • Tasks
  • Defects
  • Change Requests
  • Technical Requirements
  • Knowledge Attainment

Physical vs. Virtual Boards

When a team is physically located in the same space, it’s better to use a physical Scrum Board. The board is better utilized when it is in a common area where the team can view and access it very easily. In some companies, this board is placed by the water fountain, a place where many people gather and communicate. This can result in a better collaborative work area. If a team is geographically dispersed, it would be better to use a virtual product such as for example, VersionOne, Rally or JIRA. Following is a comparison of physical and virtual Scrum Boards as shown in Table 1.

Physical Boards

Virtual Boards

  • Forces co-location and face-to-face communication.
  • A geographically disbursed team can work seamlessly together and the Scrum Board is always visible to everyone at any time from any place.
  • The discipline needed to create consistent cards with the relevant information is easier to accomplish.
  • The virtual board has much more customization options that can be matched to needs of a business.
  • Ease in changing the process workflow.
  • More ease with workflow analysis and report preparation.
  • Physical boards create focal point for daily stand-up meetings.
  • Historical data is readily available.
  • Physical cards have space limitations.
  • Virtual cards have greater information capacity.

Table 1. Virtual and Physical Scrum Boards Comparison

Keywords: scrum, board, teams


Gunter, Stuart. (2012). Experimenting with Horizontal WIP Limits in Kanban. Retrieved from

Kanban Tool. (2017). Scrum Task Board: Apply Scrum Methodology with Kanban Tool. Retrieved from

Mountain Goat Software. (2017). Scrum Task Board. Retrieved from

RealtimeBoard, Inc. (2017). Scrum vs Kanban Boards: 11 Major Differences. Retrieved from

Scrum Inc. (2017). Scrum Board. Retrieved from




Posted on: March 05, 2018 08:43 PM | Permalink | Comments (10)

Minimizing Risks Through Scrum

Scrum is a popular agile method based on its flexibility, adaptability, and effectiveness in delivering value quickly and continuously on a project. The Scrum framework excels in comparison to traditional project management methods in the way risks are intrinsically minimized throughout the entire lifecycle. All projects are impacted by some form of risk, whether it be negative (threats) or positive (opportunities). The goal is to maximize the impact and probability of positive risks and to reduce or eliminate negative risks. This article focuses mainly on negative risks. Most projects begin with high levels of risk because of a large number of uncertainties. The Scrum framework has built-in benefits that help to keep the impact of risks at very low levels. Scrum practices inherently mitigate risk based on the following characteristics of the framework:

  1. Adaptability – Risks are minimized through Scrum based on the principle of adaptability.  This means that requirements can be changed and/or added at any time in the project. This flexibility results in the ability of an organization to adequately respond to threats and opportunities when priorities change. It is a fair assumption that priorities will change on projects. The cost of addressing these changes is very low and the process is faster when compared to traditional project management. To be clear, changes and additions to requirements are not added: “just because”. This adaptability to change is implemented only in cases when the additional value can be provided to the customer.
  2. Transparency –Information radiators such as burndown charts and Scrum boards provide needed transparency when compared to traditional methods where only the project manager has access to the project schedule.  The consistent status of the project is available and all team members and stakeholder are kept “in the know”. The Scrum principle of transparency ensures that risks are identified and communicated continuously. This results in effective risk mitigation. The Impediments Log or Risk Register (managed by the Scrum Master) tracks all risks on the project and is available to the Scrum team and stakeholders.
  3. Continuous Feedback – Due to the iterative nature of Scrum, the framework provides opportunities to get feedback throughout the project. During the Daily Standup meeting, impediments and risks are addressed on a consistent basis. The entire Scrum team is made aware of all potential risks that could impact the project on a continuous basis. This results in effective risk mitigation and surprises are effectively kept to a minimum. The Sprint review and Demo meeting is another opportunity to get feedback on the product. During this ceremony, the Scrum Master, Scrum Team, Product Owner and stakeholders review the product increment by means of a demonstration of all user stories in the Sprint Backlog. The Product Owner accepts or rejects user stories based on whether the acceptance criteria have been met. A user story may also be rejected if it needs a modification based on new information realized during the product demo.
  4. Continuous Improvement –Another benefit of implementing Scrum are the retrospectives that take place at the end of every Sprint and at the end of the project. The purpose of the “retro” is to examine the team’s processes and determine what worked; what did not work; and what needs to be included going forward for the team’s processes. The Scrum team then decides together as to which processes or actions need to be addressed by the next Sprint. This is where improvements are made on a continuous basis through retrospectives.
  5. Iterative Delivery – Business-value on the Scrum project is continuously delivered as opposed to “at the end” as with traditional project management methods. This results in risk reduction for the customer’s investments. The project deliverables are progressively improved during each (iteration) Sprint. This reduces risk to the product increment if changes need to be reversed. The development team will easily know which Sprint increment needs to be addressed.
  6. Scrum Team Ownership - The Scrum Team is responsible for estimating the Sprint Backlog. This leads to more precise estimation and timely delivery of the product’s increments. There is no one better than the Scrum team to estimate the work. This results in the reduction of estimation risk.
  7. Risk-Adjusted Backlogs - The concept behind this type of Product Backlog is the focus on delivering the highest value features and high-risk items that have been identified to be top priority work. This helps the team to deliver and mitigate the large impact risks to the project as early as possible. We know that risk represents anti-value and to deliver value, we must minimize risk.
  8. Risk-Based Spike – This type of spike is experimental and is used to identify the types of risks and their impact on a project. A risk-based spike is implemented before the project commences and can be used by the team to get accustomed to new technologies or tools needed for develop the product. Estimation uncertainties are also investigated during this time or in cases where a user story is unclear. This event is typically time-boxed for two to three days.
  9. Risk Burndown Charts – Identified risks can be identified and managed by means of a risk burndown chart. This type of chart depicts the status of risks over a period (weekly, monthly, etc.) and shows impact levels that should be decreasing. Risks are identified and tracked during the Sprint Planning meeting and monitored throughout the Sprints. The graph for the chart is created from the risk register (Figure 1). The risk burndown chart visualizes and tracks how long risks take to be mitigated. Total project risk levels can also be tracked. If risk mitigation is successful, the graph should be showing a downward slope as illustrated in Figure 2 below. The chart reflects an interpretation of the expected duration of how long a risk should be present on the project.

Figure 1: Risk Register (Agile Michael, 2016)


Figure 2: Risk Burndown Chart (Agile Michael, 2016)


Key Words: Scrum, Agile, Risks


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

Michael, Agile (2016). Risk Burndown Charts. Retrieved from


Posted on: February 09, 2018 12:01 AM | Permalink | Comments (7)

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)

"If this isn't a Strad, I'm out 50 bucks."

- Jack Benny