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/

When changes are made to software that has been previously validated, even the smallest revision has the potential to disrupt the existing code. Software developers implement Regression tests to ensure that modifications or additions to the code didn’t break any of the existing functionality. Another objective is to make sure that earlier variances are not re-introduced into the code inadvertently. Regression tests are used to show that automated tests that ran successfully the first time, will continue to run after code changes. This practice will ensure that the software has not regressed or been broken. This would mean that software components that were initially error-free have become defective due to unintentional code changes.

With Agile projects such as Scrum, the repetitive activity of running a suite of Regression tests can be very complicated and lengthy. Without the utilization of automated testing tools, referred to as Regression Testing tools, agile testing would involve a high level of complexity. Figure 1. outlines the Regression testing event that occurs in Scrum during a Sprint cycle. After development and when a product increment is added, Integration Regression Testing takes place. The code is integrated with the existing product and verified to determine if the addition did not “break” anything. A Scrum software development best practice is to re-run the appropriate regression tests after every code change to ensure that previous tests continue to pass. 

Figure 1. Regression Testing in Scrum

Regression Testing Strategy

It is believed, before Agile Methods because so popular, that Regression testing was easier. The complexity comes from Sprints that are often two weeks in duration and even shorter. Every time a software change occurs, the probability for new issues to be introduced into the software increases. Regression testing is the method used to uncover surprises in the code. An effective way to approach regression testing is by means of a “Regression Board”. Figure 2. shows a depiction of the board.

Figure 2. Regression Board

When using a Regression Board, each member of the Scrum testing team needs to identify a change that they worked on during a Sprint. Once all changes have been identified, they are arranged in a top-down order based on which ones should be tested first. The order can be based on risk levels, customer importance, or any reason applicable to the project. Other team members reorder the items based on technical or value-driven information that is known to them. Different team members add their own distinct project perspective when they rearrange the items on the board.

As the work is completed, pre-release testing commences. The Regression testing team refers to the Regression Board to make educational decisions about removing items from the list, adding additional staff to test low-risk items or possibly extending the release itself. As the testing team utilizes a distinct and organized list of regression testing items, it creates a major shift in thinking from “We don’t have enough time” to “We know what’s important and how much time we have”.

Regression Automated Testing Tools

When developers create new features, they can do their testing with automated Testing tools. This practice helps decrease risk when making code changes and results in the creation of a change detection system. Scrum projects have their own specific challenges for automation:

o Project scope not clear

o Multiple Iterations

o Light documentation

o Frequent and early automation requirements

o Stakeholder involvement

With traditional test automation, such as “test at the end” tools, also referred to as record and playback tools, a test team could not perform regression testing until after all software was developed. These types of tools don’t really support Scrum environments because there are better suited for Agile methods. Test automation at the beginning of the agile project is extremely difficult, however, as the system is completed, it then starts to become more relevant for automation.

The Regression Test Suite - User Stories

With Scrum, the user stories are selected for each Sprint and they used as the foundation for the test sets. As the Scrum team goes through each iteration, regression testing needs to be conducted to ensure that the existing functionality has not “broken” by the addition of new functionality in each Sprint. As the test team completes the Sprints, the magnitude of the regression testing increases. This is another instance of where good communication is needed among the Automation Testing and Scrum teams. The interaction between the client and the delivery team must remain collaborative. With heavy client involvement, comes more changes and more channels are needed for communications. The Test Automation methodology needs to ensure that the entire system, as it is developed, meets the business objectives for which it was intended and is fit for its purpose. Defects are automatically captured when an automated test script fails.

Exploratory Testing

With Agile Methods, exploratory testing demonstrates that the tester has value as an important component of the test process. In addition, values from the Agile Manifesto are shared:

o Individual and interactions over processes and tools

o Working software over comprehensive documentation

o Customer collaboration over contract negotiation

o Responding to change over following a plan

With agile projects, automated tests that support code are mainly done by the development team and are executed from a programmer’s viewpoint. Exploratory tests are designed to find defects that are beyond the scope of automated programmer tests. The exploratory tests focus on possible gaps where automation may be weak. These tests are not structured and are considered “freestyle”. In comparison, Automated tests are used more for regression testing and Exploratory tests are used for new features.

Test-Driven-Development (TDD)

TDD is a process that begins with creating tests for small pieces of functionality. Tests are developed before the code and it contains the specification and the validation of what the program needs to accomplish. TDD runs automated tests prior to the development of the software. TDD is often referred to as Test First-Development (TFD). Finally, TDD is the practice of modifying the code so that a test that was previously designed will pass. The TDD process is as follows:

1. Add a test.
2. Run all tests and see if any new test fails.
3. Write some code.
4. Run tests and Refactor code.
5. Repeat

Figure 3. outlines the TDD process.

Figure 3. Test Driven Development (TDD)

Keywords: regression, testing, Scrum

References:

Guru99. (2017). Test Driven Development: Learn with Example. Retrieved from https://www.guru99.com/test-driven-development.html#1

QASymphony. (2016). Developing a Regression Test Strategy. Retrieved from https://www.qasymphony.com/blog/developing-regression-testing-strategy/

QAT Global USA. (2017). Agile Meets Scrum in QAT Global’s Enterprise Development Framework. Retrieved from http://www.qat.com/agile-scrum-methodology/

SmartBear Software. (2017). What is Regression Testing? Retrieved from https://smartbear.com/learn/automated-testing/what-is-regression-testing/

Software Testing Help. (2017). Automated Regression Testing Challenges in Agile Environment. Retrieved from http://www.softwaretestinghelp.com/automated-regression-testing-challenges-in-agile-testing-environment/

Testing Excellence. (2017). Why Exploratory Testing is Important in Agile Projects. Retrieved from https://www.testingexcellence.com/exploratory-testing-important-agile-projects/

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 Sprint Planning Meeting

The Sprint Planning meeting is the Scrum ceremony where the team estimates all tasks associated with each user story in the Sprint backlog. The estimation effort focuses on all resources required to complete the tasks for each Sprint. A shared task list is used to estimate the duration and effort for each user story in the backlog. This practice results in a shared team perspective, resulting in a task estimation process that is consistent and reliable throughout all Sprints.

Estimation Techniques

The most commonly used Scrum estimation technique is the practice of using story points to represent the value of a user story or task. This method is used for estimation based on the relativity of a backlog item to similar items. To be clear, many Scrum teams use story points for task estimation, but it is much more common to use hours as the unit of measure for tasks.

A story point can be set for any value that a single Scrum team decides upon. Some teams assign the value of 1 week to a story point and other teams set the story point value to 1 hour or 1 day. There is no established value for a story point, however the value should be consistent throughout a Scrum project, or least within the same team. For example, if it has been decided that a story point has a value of 1 day, then 3 story points would equal 3 days. Figure 1 shows the relationship between epics (large user stories that need to be further broken down), user stories (requirements) and tasks (actual work to be done to develop the user story). Story points do not measure how long it will take to complete a user story or task.

Story points are typically based on the Fibonacci sequence which is a number sequence where every number is the sum of the previous two. The sequence goes like this: 0, 1, 2, 3, 5, 8, 13, 21, etc. This technique is called Scrum Planning Poker where the Scrum team works to create accurate estimates. Planning Poker does not represent “hourly” estimates because a story point is an abstract measurement of size. Story points help understand relative levels of effort (LOE) for a user story or task in comparison to other stories and tasks.

Figure 1: Backlog items

Decomposition of Tasks

The task list contains all assignments that are needed to complete the user stories in the Sprint Backlog. High-level tasks are decomposed into smaller tasks with greater detail. The level of decomposition should be sufficient to create product deliverables from the items on the task list.

Task Dependencies

Dependencies between the user stories and tasks should be evaluated, including those that are related to technical and staff availability. There are several types of dependencies that need to be discussed:

• Mandatory dependencies – This category includes dependencies that are for example, a result of contractual or legal related requirements. Physical limitations fall in this category and are referred to as “hard logic”, which are essential to the project work. An example of a mandatory dependency is completing work in a sequential order rather concurrently.

• Discretionary dependencies – This type of dependency represents those that are optional and are not required. The Scrum Team often considers discretionary dependencies as those that could be based on prior experience or best practices.

• External dependencies – These types of dependencies are based on tasks, products or activities that are outside of the scope of the project work and outside of the Scrum team’s control.

• Internal dependencies – These are based on tasks, products or activities that are within the control of the Scrum team. Basically, these dependencies are a part of the project work.

Estimate Tasks in Ideal Time

To recap, estimation criteria is expressed in two ways, story points (a measure of size, risk and complexity) and ideal time (a measure of time with no interruptions). The concept of ideal time describes the number of hours or days that are required to complete the work for the project’s deliverables. It is important to understand that ideal time does NOT include any time for work that is outside of the project’s scope. Ideal time represents the interval needed to do work without any interruptions (phone calls, lunch, meetings, etc.). Ideal hours are used to provide “time-based” estimates for development tasks. It is common that most estimates are excessively inaccurate where ideal estimates typically have realistic durations. Let’s look at how ideal time is calculated. We will look at ideal time in terms of days and hours. 9 developers on a Scrum Team

• 2 week Sprints = 10 ideal days = 80 hours available hours per Sprint
• The team works 7 hours per day = ideal hours = 7*10 = 70 hours per 2-week Sprint per developer
• The total ideal hours = 10*9*7 = 630 total hours of work for a 2-week Sprint
• 630 total hours divided by 9 = 70 hours per 2-week Sprint for each developer

To summarize, ideal time represents how long a task takes if:

• The task being worked is the only task that a team member is working
• There are no interruptions while the task is being worked
• Everything that is needed to complete the task is available

Elapsed time represents the total amount of time used to finish project work. Ideal time and elapsed time are not equivalent. If estimates were based on elapsed time, then ALL interruptions would need to be included.

There are several advantages and disadvantages in using ideal time:

• Using story points rather than ideal time is faster
• Ideal days can change based developers becoming more talented
• Ideal days can be distorted by actual days
• Discussions about ideal days are longer because of its potential unknown accuracy level
• One team member’s “ideal days” are not the same as another team member’s “ideal days”
• Ideal days are easier to explain to those that don’t belong to the Scrum team

Key Words: Tasks, Estimation, Scrum

References:

Canty, Denise. (2015) Agile for Project Managers (Best Practices and Advances in Program Management). Boca Raton, FL: CRC Press

Cohn, Mike. (n.d.) Chapter 8: Choosing between Story Points & Ideal Days.  Retrieved from http://athena.ecs.csus.edu/~buckley/CSc231_files/Cohn_Ch8.pdf

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

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/