Agile Thoughts

Programs represent a collection of related projects. The objective of a program is to produce business results as they have been identified in the Program Vision Statement. The Prioritized Program Backlog includes Product Backlogs for every project within the program. According to the Scrum Body of Knowledge (SBOK), the Program level includes five (5) major processes.

1. Create Program or Portfolio Components – For programs, this process requires that the Program Product Owner, along with key stakeholders identify the common components and resources that are a need for the program. In addition, the “Minimum Done Criteria” is established and the key stakeholders are pinpointed. Figure 1 summarizes the process in greater detail.

Figure 1: Create a Program or Portfolio Components

2. Review and Update Scrum Guidance Body – For programs,

Figure 2: Review and Update Scrum Guidance Body

3. Create and Groom Program or Portfolio Backlog

Figure 3: Create and Groom Program or Portfolio Backlog

4. Coordinate Program or Portfolio Components

Figure 4: Coordinate Program or Portfolio Components

5. Retrospect Program Releases

Figure 5: Retrospect Program or Portfolio Releases

References:

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

SCRUMstudy. (2014). Scrum Methodology in Projects, Programs, and Portfolios. Retrieved from https://www.scrumstudy.com/blog/scrum-methodology-in-projects-programs-and-portfolios/

Agile projects often have a high degree of uncertainty; namely, there are absent features and time estimates that have a high probability of adversely impacting the business. To avoid a negative impact, estimates should be buffered to reflect levels of uncertainty that are intrinsic in estimation activities. This article is a discussion of the various types of buffers used to minimize uncertainty during planning with Agile Methods.

Sprint Planning Buffer

The rationale for conducting an Agile Planning meeting is for the purposes of presenting the User Stories to the Agile Team for estimation. The outcome of this meeting is the team being aligned with the business objective. The team is expected to be committed to accomplishing the work required to complete the User Stories in the Sprint Backlog. The first and most important process in the Agile Planning meeting should be determining the team’s velocity. Methods for calculating the team’s velocity include but are not limited to the following.

1. The team’s capacity can be calculated based on the following formula:
   1. (Number of team members) X (Number of days in the iteration) X (6 hours)
2. During the Planning meeting, team members who have planned vacation time during the approaching Sprint should be identified and captured as a “vacation user story”. This user story should have tasks that represent each team member’s time out of the office. This will account for some of the team’s velocity, represented as user stories during the committed process of planning. Once the Sprint is in progress and the vacation days have approached, the burndown chart will reflect the vacation days tasks as being completed along with other tasks. The burndown chart will correctly reflect the team’s velocity due to vacation and time away from the office. As an example, we use a six-member Agile Team that is planning a 10-day Sprint to calculate the capacity of the team:

(6 members) X (10 days) X (6 hours per day) = 360 hours capacity.

The daily burndown is then calculated as (360 hours of capacity) divided by (10-day Sprint) is equal to 36 hours.

The Sprint capacity is determined using the assumption that all team members have only six-hour available hours to do work per day. This is a Sprint Planning Buffer that keeps the team from being over-obligated. This approach takes into consideration all team disruptions such as lunchtime, meetings, and any time away from the office. This buffer is applicable to Lean Software Development under the principle, “Limit work to capacity” which helps to ensure a highly productive and sustainable development pace.

Feature Buffering

Features have changing levels of importance to customers, and they represent the “must haves” and the “should haves”. An agile project is planned with the intention of delivering functionality and providing flexibility. The customer identifies the features that the project is required to deliver based on business value and then continues this process until most of the remaining work that is non-critical has been selected. During the process of estimating all user stories, it will become clear that the project will be besieged. This will require the removal of the additional features from the schedule so that the project will get back on track. The percentage of additional features to be included is based on the magnitude of uncertainty that needs to be buffered and the project size.

Schedule Buffers

To inject a buffer into the project schedule, the level of uncertainty needs to be identified. We should not randomly apply padding into the schedule, rather we should establish a valid range. To be more accurate with our uncertainty calculation, we need to start with two distinct numbers for estimation purposes.

1. Our best uncertainty estimate is the 50%, which mean that there is a 50% chance that the project is finished on time and a 50% chance that it won’t be.
2. The worst uncertainty estimate is the 90%, which represents a 90% certainty regarding the time needed to complete a task. The additional time in-between the estimates is referred to as a local safety value.

If we add up all local safety values and use them as buffers, it will be inaccurate because it’s not probable that things will go incorrectly to this extent. Using two estimates is a better approach because it represents the uncertainty in the estimate and this allows us to come up with the risk linked to each user story. When we buffer our project to our 90% certainty estimate, we need a buffer that has two standard deviations. This means that we calculate the following:

1. Determine the local safety value for each feature
2. Square each local safety value
3. Total all squared local safety estimates
4. Calculate the square root of the total
5. The residual number is the buffer estimate and is added to the initial estimate to calculate a range.

 See Table 1 below for an example:

Table 1. User Story Best & Worst Estimates

Our calculations are shown in Table 2 below.

Combining Buffers

So that we experience as much risk reduction as possible, it is helpful to combine buffers. This means that we could indicate that our project will finish the following:

1. All Core features
2. Between 0% to 100% of extra features
3. The features will be finished during a point between the original estimate and the buffered estimate. This is done to give customers more flexibility when calculating the end date for the project. Figure 1 is an illustration of combining buffers.

Figure 1. Combining Buffers

References:

Mining Code. (2014). Agile Planning and Estimation. Retrieved from http://seantrobinson.co.uk/agile-planning-scheduling-2/

Scrum Alliance. (2008). Perfect Planning. Best Practices for Successful Planning. Retrieved from https://www.scrumalliance.org/community/articles/2007/august/perfect-planning

The Scrum Guidance Body (SGB) typically consists of a group of professionals that define the set of standards that pertain to quality, government regulations, and other important organizational considerations. The standards are developed to provide guidance for the Product Owner, Scrum Mater and the Scrum Team. The SGB also is responsible for capturing Scrum Best Practices for use by all Scrum projects within an organization. Decision-making at the project level is not supported by the SGB; rather it provides guidance and/or the consulting foundation for all organizational project related levels (i.e. portfolio, program, and project). The Scrum Team is free to utilize the SGB as they need advice. Recommendations from the Scrum Guidance Body should be used on Scrum projects to ensure of the proper alignment of the project vision and process compliance to the standard and guidelines that have been established by the Body. Although the SGB is an important role, it must be understood that the Body is optional.

Scalability Recommendations

Scalability refers to the ability to adapt to any type of expansion. For Scrum, it means that a single Scrum Team can be scaled for larger projects by means of multiple teams. The Guide to the Scrum Body of Knowledge (SBOK Guide) has provided specific steps that support Scrum’s ability to be scaled and applied on large projects. Scalability in Scrum can be applied at three levels: Projects, Programs and Portfolios. The process begins with the Scrum of Scrum (SoS) meetings that support harmonization between multiple Scrum Teams. A representative from each of team provide feedback regarding their team’s progress, issues confronted and synchronization activities. The frequency of the SoS meeting is based on recommendations from the SGB, complexity level, project size and dependencies between the teams. Other recommendations include co-location and face-to-face communication among the Scrum team. As many of us may have experienced, co-location is sometimes very difficult to achieve. Companies often use distributed teams that work in different time zones and a variety of geographies. Regarding scaling for large projects, geographically dispersed team use chats, social media, video conferencing and other virtual communication practices.

Large Project Considerations

With projects that create large components, it is important to understand the role of multiple Product Owners and the way that multiple Scrum Teams work together. We will now discuss the inputs that are necessary for creating large project components in Scrum. Basically, the role of the Product Owner stays for same for small and large projects. The difference is that for large projects, the PO will not make daily decision a priority. Instead, the PO provides input and recommendations to the Chief Product Owner. Stakeholder interactions are distributed between all Product Owners and each one continues to work with their designated team. Role and responsibilities are captured in the Product Owners Collaboration Plan. Large project planning often results in recommendations to revise or improve the Scrum Guidance Body recommendations. If the body accepts the proposed modifications or additions, they will be added as updates to the SGB documentation. Figure 1 outlines the workflow for the creation of the large project components.

Figure 1. Create Large Project Components – Data Flow Diagram

Chief Product Owner

The Chief Product Owner is responsible for making daily business decisions on large projects. This role is responsible for the coordination of work for multiple Product Owners. With feedback from the POs, the Chief PO is responsible for the preparation and maintenance of the Prioritized Product Backlog, which is used as the source of work for the Product Owners and their Scrum Teams. Finally, the Chief PO takes care of the final deliverable for the projects. Lastly, each PO for the Scrum Teams is responsible for only the component and features that are developed by their assigned Scrum Teams.

Project Vision

The project vision clarifies the business need for the project. This statement should not be specific and needs to have room to be very adaptable. The reasons behind this flexibility are because it is very probable that the project could be based on suppositions that could change as the project progresses. The project vision must be able to accommodate changes and it should focus on the problem and NOT on the solution.

Chief Scrum Master

The Chief Scrum Master has the responsibility for communicating information and managing dependencies between the Scrum Teams on large projects. Collaboration is required among the Scrum Team via the Scrum of Scrums (SoS) meetings. One of the main responsibilities of the Chief Scrum Master is to remove impediments and fostering a productive environment for the Scrum Teams. This role also collaborates with the Chief Product Owner, Scrum Masters, and Product Owners to establish a list of components and resources needed across all Scrum Teams. As expected, the Chief Scrum Master is expected to facilitate all ceremonies that exceed the responsibilities of a single Team Scrum Master. There is also consistent interfacing with the Program Scrum Master to make sure that there is the proper association of the large project with the goals and intentions of the related program.

Large Project Environments

For large projects, it is important to determine the number and types of environments needed for a large number of Scrum Teams to accomplish their work during their Sprints. These categories of environments include but are not limited to testing, development, work locations, resources or applicable procedural borders required for the Scrum Teams.

Definition of Done

The SGB generally defines and documents the Definition of Done. The “Done” criteria represent a set of rules that will be applied to all user stories in a specific Sprint, including but not limited to the following:

• Team Reviewed
• Unit Testing Completed
• Quality Testing Completed
• All Defects Corrected
• Demo Successful
• Documentation Completed for each user story

References:

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

SCRUMstudy. (2017). Scalability of Scrum. Retrieved from https://www.scrumstudy.com/blog/scalability-of-scrum/

SCRUMstudy. (2017). Inputs Required for Creating Large Projects in Scrum. Retrieved from https://www.scrumstudy.com/blog/inputs-required-for-creating-large-project-components-in-scrum/

SCRUMstudy. (2017). What are Done Criteria? Retrieved from https://www.scrumstudy.com/blog/what-are-done-criteria/

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.

Table 1. Retrospective Metrics

Velocity

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

References:

Agile Alliance. (2015). Glossary. Velocity. Retrieved from https://www.agilealliance.org/glossary/velocity/

Agile Alliance. (2015). Peer Feedback. Retrieved from https://www.scrumalliance.org/community/articles/2015/january/new-innovation-to-scrum-ceremonies-peer-feedback

Agile Velocity Blog. (2014). Improve Your Visibility into Release Progress. Retrieved from http://www.agilevelocity.com/blog/release-planning/

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

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.

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.

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.

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

References:

CoreWorks. (2014). The Impediments Backlog. Retrieved from http://www.coreworks.co/scrum-impediments-backlog

Getting Agile. (2011). Organizational Impediment Management: Early Risk Detection for Agile. Retrieved from http://www.gettingagile.com/2011/01/24/organizational-impediment-management-early-risk-detection-for-agile/

LeanAgileTraining. (2017). What are Impediments? Retrieved from https://www.leanagiletraining.com/impediments/what-are-impediments/

Openbravo wiki.  (2009). Scrum/Impediment. Retrieved from http://wiki.openbravo.com/wiki/Scrum/Impediment

Overeem, Barry. (2016). The Scrum Master as an Impediment Remover. Retrieved from http://www.barryovereem.com/the-scrum-master-as-an-impediment-remover/

Scrum Alliance. (2011). Five Tips for Impediment Resolution With Scrum. Retrieved from https://www.scrumalliance.org/community/articles/2011/september/five-tips-for-impediment-resolution-with-scrum

scruminc. (2017). Impediments. Retrieved from https://www.scruminc.com/impediments/