15 Running with Scrum

As mentioned previously, Cheryl, the CIO, had after a series of successful endeavors mandated that scrum and either user stories or use cases be employed by all development teams. One reason why organizations often mandate specific practices and tools is to simplify training and communication. Recall that a practice is defined to be: A repeatable approach to doing something with a specific purpose in mind. By making a practice explicit we improve communication reducing the chances of someone misunderstanding how the practice is intended to be carried out.

Scrum is perhaps the most popular agile practice at the time of this writing. Jeff Sutherland and Ken Schwaber created Scrum to get teams to work iteratively and to collaborate more effectively by following a number of practical and proven activities.

15.1 Scrum Explained

Figure 78 shows a big picture overview of Scrum [14]. It provides explicit guidance related to how a small development team with about 7 plus minus 2 team members work together. Henceforth we will refer to that team as a Scrum team. All the work that the team might have to do is first placed in an ordered list - the Product Backlog. The Product Backlog is maintained with the most important items near the top of the list. The things in the product backlog are called Product Backlog Items (PBIs). A PBI can be a piece of a requirement, something the team can do to improve themselves, or defects, which they will have to fix.  

Figure 78       Scrum Big Picture

The heart of Scrum is the Sprint, a fixed length period of time, usually one to four weeks, during which the team meets a certain goal, which includes producing a Potentially Shippable Increment of the product to be developed. The PBIs to be performed in a Sprint are selected through the Sprint Planning activity where the team, together with the Product Owner, agrees on the highest prioritized PBIs to be worked on in the upcoming Sprint. These PBIs are moved from the Product Backlog to the Sprint Backlog.  This activity is done on the first day of each Sprint by the full Scrum team working together to determine what can be delivered and how it can be delivered in the agreed to Sprint time period. There are two parts to the Sprint Planning activity. During the first part the Product Owner explains to the team the goals of the Sprint and the Product Backlog Items that, if implemented, would achieve the Sprint goal.

The goal gives the Scrum team some flexibility regarding the functionality implemented within the Sprint. During the second part of the meeting the team forecasts the Product Backlog items (PBIs) it will achieve and crafts their agreed upon Sprint goal. Those PBI’s are then moved to the Sprint backlog (e.g. the agreed work to be done in the current sprint). 

Each day during the Sprint, the team meets to synchronize their work and create a plan for the next 24 hours.  This is called the Daily Scrum and is limited to 15 minutes.  At the Daily Scrum, each team member explains what he/she did since the last meeting, what s/he plans to do today, and what is getting in her/his way preventing her/him from meeting the Sprint goal.  Solutions to problems are not discussed in the Daily Scrum.  A separate meeting is arranged to dive deeper into problems when necessary.

At the end of the Sprint, the team conducts a Sprint Review activity with key stakeholders to review the product (referred to as a potentially shippable increment) they have produced. At this review stakeholders may also identify product improvements (PBIs) that will be placed in the Product Backlog. At the end of each Sprint, the team holds a Sprint Retrospective activity.  The Sprint Retrospective is an opportunity for the Scrum team to agree on improvement to their way of working to be implemented in the next Sprint. 

There are three major roles in Scrum, namely the Product Owner, the Scrum Master and Developers. The Product Owner (PO) is responsible for feeding the Product Backlog based on his interaction with customers and users. The PO is also responsible for prioritizing the PBIs. The team members (i.e. developers) are responsible for estimating the effort for implementing each PBI.

The Scrum Master role is something unique to Scrum. The Scrum Master is a servant leader, a person who facilitates the Scrum activities and motivates the team members to follow the Scrum activities.

While the Scrum activities we have just described are fairly simple, teams often tailor them based on their own situation.  This is one reason why capturing a team’s agreed to way of working as a set of explicit practices can help team members - especially new and less experienced team members - understand what activities are expected, options they have in carrying out these activities and how much detail is expected in any related work products. 

15.2 Practices Make a Software Engineering Approach Explicit and Modular

Scrum is in essence, a practice, or rather, a set of practices. Briefly speaking, a practice is about doing stuff in a certain way to address certain problems, and with scrum, it is about team improving team collaborations and performance. We will take a slight detour to explain how Essence captures practices in an explicit way and thereby provide practical guidance to teams. We will in a short moment capture the Essence of scrum and demonstrate how Smith’s team apply scrum.

The word “practice” is an overloaded word meaning different things to different people. The Essence specification provides a definition: A practice is a repeatable approach to doing something with a specific purpose in mind. A practice provides a systematic and verifiable way of addressing a particular aspect of the work at hand. It has a clear goal expressed in terms of the results its application will achieve. It provides guidance to not only instruct practitioners in what is to be done to achieve the goal but also to ensure that the goal is understood and to verify that it has been achieved.

As such, a practice provides a proven way of approaching or addressing a problem. It is something that has been done before, can be successfully communicated to others, and can be applied repeatedly producing consistent results.

15.3 Making Scrum Explicit Using Essence

Scrum can be represented as a practice that is set of activities to help teams conduct iterative development in a highly collaborative manner. In part 4 of the book, we will show a different way to represent Scrum as a composition of multiple practices. That is, a Product Ownership practice, a Backlog practice, an Iterative Development practice, and a Retrospective practice. Thus, Scrum is not simple, and indeed, the Scrum Guide [14] calls Scrum a process framework. For the purpose of this part of the book, we choose to use a simplified version of Scrum, which we represent as a single practice that we call Scrum Lite. While our Scrum Lite includes what we have assessed to be the important elements of Scrum, we do not include a discussion on the ideas of Scrum, all of the responsibilities of all of the Scrum roles, nor do we include all of the characteristics of a Scrum Team. 

Different practice authors will have different ways to express their key concepts. So, Scrum will be expressed in one way (as depicted in Figure 78), User Stories another way, Use Cases another way, and Microservices yet another way. They didn’t use a common ground, because they didn’t have one. They use different terms for the same thing and the same term may have different meaning in their practices. Some authors deal with this problem by re-describing what the original author developed, but they don’t use a standard like Essence, rather they create their own terms. This doesn’t create a collaborative environment between the people who have contributed their ideas to the world.  This is one of the serious problems Essence addresses – every author uses the same standard language.  It becomes significantly easier for students to learn many practices.  Once they have learned one practice, they will while learning a new practice recognize that there is a lot in common even if the new practice covers a different topic than the first practice. And the more practices they learn the easier it becomes to learn something new.

We can redraw the Scrum Lite big picture in Figure 78 using the Essence language as shown in Figure 79.

Figure 79       Scrum Big Picture Mapped to the Essence Language

What you see in Figure 79 is the Scrum big picture elements represented using the Essence language symbols.  For example, the figure reminds us that Product Owner, Scrum Master, and Scrum Team roles are represented as patterns in the Essence language. And Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective are Activities. Product Backlog, Sprint Backlog, and Increment are Work Products.  And finally, Sprint and Product Backlog Item are alphas in the Essence language.   

A complete model of the Scrum practice is shown in Figure 80.

Figure 80       Scrum Lite Practice Expressed in the Essence Language

Figure 80 is a useful diagram in that it shows:

  1. Relationships between the elements in the practice, such as the relationships between Sprint, Sprint Backlog, Product Backlog, Product Backlog Item and Increment
  2. Activity flows, such as from sprint planning to daily scrum to sprint review and sprint retrospectives
  3. Relationships with kernel elements, such as between Work and Sprint, Product Backlog Item and Requirements, Increment and Software System.

Thus, Figure 80 not only shows the relationships between elements in the practice, in this case the Scrum practice, but also the relationship with the kernel, and through that you are better able to understand how Scrum provides more guidance on top of what is available in the kernel. 

An important concept heighted in Scrum is the “Definition of Done” (DoD).  The DoD is a clear and concise list of criteria that each Product Backlog Item must satisfy for the team to call it complete. As an example, Product Backlog Item may include DOD criteria such as:

  • Sufficiently tested.
  • Accepted by the Product Owner.
  • Source code checked-in.
  • Associated documents (e.g. user manuals) updated.

The DoD must apply to all items in the backlog. It can be considered a contract between the Scrum team and the product owner. The purpose of DoD is similar to the purpose of the checklists of alpha states. They provide an explicit definition of what the team members must do. DoD as provided through the alpha state checklists are available for Product Backlog Items and Increments, and in general any alpha or work product. Alpha states go one step further by defining the completion criteria for each state.

15.4 Elements of the Scrum Lite Practice

Table 6 provides a summary of the elements in the Scrum Lite practice.

Table 6           Elements of Scrum Lite Practice

Element

Type

Description

Sprint

Alpha

A time-box (e.g. fixed length of time) of one month or less during which a "Done", useable and potentially shippable Product Increment is created. A new Sprint starts immediately after the conclusion of the previous Sprint.

Product Backlog Item

Alpha

A change to be made to the product in a future release (for example a feature, user story, requirement, enhancement or fix).

Sprint Backlog

Work Product

The set of Product Backlog Items selected for the Sprint, plus a plan for delivering the Increment and realizing the Sprint Goal. The Sprint Backlog makes visible all of the work the Development Team identifies as necessary to fulfill the Sprint Goal.

Product Backlog

Work Product

A priority ordered list of everything that might be needed in the product. The single source of requirements for any changes to be made to the product. The items in the Product Backlog are known as Product Backlog Items.

Increment

Work Product

The sum of all Product Backlog Items completed during a Sprint and those items completed during all previous Sprints. The Increment must be "Done", which means the Software System it describes must be usable and meet the Definition of Done.  When a Product Backlog item or an Increment is described as Done”, everyone must understand what “Donemeans. Although this varies significantly per Scrum Team, members must have a shared understanding of what it means for work to be complete, to ensure transparency. This is the Definition of Done for the Scrum Team and is used to assess when work is complete on the product Increment.

Completed includes only items that meet the team’s agreed to Definition of Done.

Daily Scrum

Activity

The team meets every day, same time and place, to assess progress, synchronize activity and raise any issues that are getting in their way and require action to resolve. The meeting is time-boxed, typically to 15 minutes.

Sprint Planning

Activity

Decide what can be delivered in the Sprint's Increment and how the work needed to deliver the agreement will be achieved.

Sprint Review

Activity

A time-boxed review of the outcomes of the Sprint to gather feedback and discuss what should be done next.

Sprint Retrospective

Activity

The whole team meets at the end of the sprint to reflect on its way of working. Improvements are identified and prioritized, and actions agreed. At the next retrospective, the results are evaluated.

Product Owner

Pattern

The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals. The Product Owner is the sole person responsible for managing the Product Backlog.

Product Backlog management includes:

Clearly expressing Product Backlog items:

  • Ordering the items in the Product Backlog to best achieve goals and missions
  • Optimizing (maximizing) the value of the work the Development Team performs
  • Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
  • Ensuring the Development Team understands items in the Product Backlog to the level needed.

Scrum Master

Pattern

The Scrum Master is responsible for ensuring that Scrum is understood and enacted. The Scrum Master is a servant leader for the Scrum Team. Amongst other things the Scrum Master helps:

  • Guide Scrum activities
  • Remove impediments
  • Ensure everyone understands Scrum
  • The Scrum Team understand the need for clear and concise product backlog items

Scrum Team

Pattern

The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams deliver products iteratively and incrementally, maximizing opportunities for feedback on how they are doing and self-improvement.  The best Scrum Team size is small enough to remain nimble and large enough to complete all significant work within a Sprint.

 

15.4.1 Scrum Lite Alphas                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      

In this section, we will introduce each of the alphas that comprise the Scrum Lite practice. These alphas are the Sprint alpha and the Product Backlog Item alpha. 

15.4.1.1 Sprint

As mentioned, a Sprint is a time-box (e.g. fixed length of time) whereby some useful work is completed.

Figure 81       The Sprint alpha

In the Scrum guide [14], there are no explicit alpha states defined. However, we find that alpha states are very useful for teams who are new to Scrum. They help teams understand what they must do to prepare for their sprints and for each activity in a sprint. In our Scrum lite practice the Sprint alpha states are as follows:

  • Scheduled – The start and end dates for the sprint is scheduled and all team members are aware of the dates, there are sufficient backlog items in the product backlog, and the backlog items have been prioritized.
  • Planned – The goals to be achieved in the sprint have been agreed, including the specific backlog items within the scope of the sprint, and the risks have been identified and the team has agreed how to mitigate them.
  • Reviewed – The outcome of the sprint has been reviewed. This includes reviewing the product increment (such as the recommendation engine), and the team’s way of working.  This includes reviewing which specific backlog items have been completed, which ones were not completed, why they were not completed, how the team can improve their way of working, and what improvement actions they can take.

In companies, these Sprint alpha states will often be tacit. However, for new students to Scrum, these states and checklists are very useful; new students have not learned the essence of Scrum and can’t easily figure it out on their own. By providing the checklists, a less experienced developer would be guided from making unnecessary mistakes. Figure 82 shows the alpha state checklists.

Figure 82       The Sprint alpha state cards

These simple checklists are also a good source for information for learning and even for experienced developers as reminders since experienced developers can easily forget what they previously learned. However, being too prescriptive might prevent the practitioner from thinking on his/her own, and treating the checklists as the word of God. Like all things, it is about striking a balance between what should be left tacit and what should be made explicit. In our Scrum lite practice we intentionally did not add a fourth state for retrospective completed to the Sprint alpha.  The value of such a state is something each organization can decide based on their own situation including the competency of its  people.

15.4.1.2 Product Backlog Item

A product backlog item (PBI) is a change to be made to the product in a future release (for example a feature, user story, requirement, enhancement or fix).

Figure 83       The Product Backlog Item alpha

The alpha has the following states identified in Figure 83, namely:

  • To Do – It has been agreed that the product backlog item needs to be completed within the next sprint. The scope and completion criteria of the product backlog item are clear.
  • Ready – The team works together with the product owner to agree on how they should go about completing the product backlog item.
  • Doing – At this state, the team is working on the item and bringing it to completion.
  • Done – The product backlog item has been completed.

15.5 Scrum Lite Work Products

The Scrum Lite practice comprises the following work products, namely:

  • Product Backlog
  • Sprint Backlog
  • Increment

15.5.1 Product Backlog

A product backlog work product is a priority ordered list of everything that might be needed in a product. It is the single source of requirements for any changes to be made to the product. The items in the product backlog are known as product backlog items.

Figure 84       The Product Backlog work product

The levels of detail in a product backlog are one only:

  • Items Ordered – The product backlog items are captured in the product backlog. This can be in the form of a spreadsheet or within some backlog management tool. They are ordered according to their priority, so that high priority ones can be selected for the next Sprint Backlog

For more sophisticated endeavors, there might be more levels of detail. For example, the team might want to describe rationales for prioritizing the Product Backlog Items, so that team members can avoid unnecessary debates.

15.5.2 Sprint Backlog

A sprint backlog work product is the set of product backlog items selected for a sprint. It also includes a plan for delivering an increment realizing the agreed upon sprint goal. A sprint backlog makes visible all of the work the development team identifies as necessary to meet the sprint goal.

Figure 85       The Sprint Backlog work product

The Sprint Backlog comprises the following levels of detail:

  • Goals Specified - The Sprint goal is clearly stated and sets the target for the team members.
  • Capacity Described - The amount of work the team can perform is estimated. In this way, the team can determine if it has too much or too little work in the Sprint.
  • Work Forecast Described - The team agrees on product backlog items that can be completed within the sprint, as well as target dates they expect to complete within the Sprint.

15.5.3 Increment

An Increment is the sum of all product backlog items completed during a sprint and those items completed during all previous sprints.

Figure 86       The Increment work product

The Increment work product has the following levels of detail:

  • Completed Product Backlog Items Listed - The Product Backlog Items that make up the Increment are clearly listed.
  • Increment Notes Described – Further information about the Increment is provided such as environments, in which the increment can work, known issues, and so on.  By environment we mean which browser version, which operating system, and similar. The specific content has to be agreed upon by the team.

15.6 Scrum Lite Roles

Scrum Lite identifies explicitly two roles, namely the Product Owner and Scrum Master. A role is a list of responsibilities that one or more people accept. The individuals serving as Product Owner and Scrum Master and the rest of the team members form the scrum team. Essence allows you to model roles and team organization as patterns.

In part 1 you learned that Essence provides a concise representation of patterns as poker-card-sized cards. Figure 87 shows the Product Owner pattern card, which comprises the most important information about the Product Owner’s responsibilities. The card shows that the Product Owner is responsible for managing the product backlog and ensuring each item is clear to the team members and ensuring the product backlog is visible to the team. The card also shows that the Product Owner is responsible to ensure the value generated by the Scrum team is optimized which means the work of the Scrum team provides value toward achieving the goal of the sprint. 

Figure 87       The Product Owner card

The Scrum Master role is also represented by a pattern as in Figure 88. The individual acting as the Scrum Master coaches the team as they conduct the Scrum activities. When team members face impediments, such as unclear backlog items, he/she works to remove the impediment. As an example, Smith’s team faced an impediment with using a library, which required licensing fees. If the licensing is not resolved, Smith’s team might have to rewrite a part of the software. Smith discussed the problem with the company legal representative and finance officer. After discussion, they agreed to use an alternative library that didn’t require licensing fees, which resolved the impediment.

Figure 88       The Scrum Master pattern card

The third pattern in Scrum Lite is the Scrum Team, which is a team pattern in Figure 89. The Scrum team consists of members, two of which play the roles of a Product Owner and a Scrum Master. Scrum teams are self-organizing which means no one outside the team tells the team how to achieve the goal of each sprint.  The team includes people with the needed competencies to accomplish all the required work. This is sometimes referred to as a cross-functional team.

  

Figure 89       The Scrum Team pattern card

These cards can be used by Scrum team members by placing them on a board or having them carry them in their pockets where they can be easily accessed as quick reminders of their agreed to responsibilities.

Thus, Angela agreed to be the Product Owner, and Smith agreed to take on the Scrum Master role for the development team. 

15.7 Kick Starting Scrum Lite Usage

When Smith’s team discussed how they would apply Scrum Lite, there were many questions. Tom, a rather senior and vocal developer, asked, “How would using Scrum Lite differ from what we did when we delivered the demo? We have been providing demos to Angela on a weekly basis and we adapted our plans based on her feedback.”

Smith replied, “Yes, indeed that is true, but Scrum Lite does have some things we can learn that can help us improve the way we are currently working. We did not do Daily Stand Ups to highlight problems early and improve our team communication. We did not actively manage our Requirement-Items in a backlog. We did not define and assign roles with explicit responsibilities, such as Product Owner and Scrum Master. This might be OK when we were producing the demo for Dave. Now that we are working towards a live product, and our endeavor has greater visibility to management we need a way to ensure our team operates with appropriate discipline. We also did not really prioritize our work when we did the demo, nor did we estimate the effort.” Making Scrum activities explicit helps team members apply the practices they have agreed to use.  The explicit definitions act as reminders to team members. Also by using Essence to describe practices, we will be able to see any gaps we may have in our practices that we need to fix. This is because when we express practices using the Essence language we can see which kernel alphas are being progressed, and we can see which ones are not being affected. If an alpha is not being affected by a certain practice it should lead the team to ask if they have another practice that is helping them progress that alpha.  They may or may not need an explicit practice for every alpha, but the team should discuss this and decide based on their specific situation.  Once the team has agreed to the set of explicit practices they need, the cards can be used as visible reminders.  

Tom asked, “How would the alpha state cards be used now that we are using scrum? ”

Grace replied, “I think one way would be to use the Health Monitor game to help us keep the status of each increment visible to our development team. We can easily incorporate this game into our sprint planning, review and retrospective activities by keeping the green stickers and red stickers up to date on the board with our alpha state cards (refer to part 2, chapter 11 for information on green and red stickers). This can remind us to discuss problems as soon as possible.“

All in all, the team members were eager to use Essence and the cards along with Scrum to help learn from their experiences. They agreed to move forward with Scrum as summarized in Table 7.

Table 7           Adopting Scrum Lite in TravelEssence

Scrum Element

How the TravelEssence team did it

Product Owner

Angela would be the Product Owner for the team.

Scrum Master

Smith would be the Scrum Master for the team.

Sprint

Smith’s team agreed that they will iterate on a weekly time box.

Sprint Planning

Weekly (Every Monday morning)

Daily Scrum

Every morning (Tuesday, Wednesday, Thursday)

Note, Mondays and Fridays were for Sprint Planning and Reviews, and Retrospectives.

Sprint Review

Weekly (Every Friday afternoon)

Sprint Retrospective

Weekly (Friday afternoon after sprint review)

15.8 Working with Scrum Lite

Smith, in his role as Scrum Master, made sure that the activities in Scrum Lite were observed as this would get the team into a working rhythm useful for nurturing good habits.

Working with Scrum Lite involves the activities like:

  • Sprint Planning,
  • Daily Scrum,
  • Sprint Review, and,
  • Sprint Retrospective.

We will explain these activities and how Smith’s team performs them.

15.8.1 Sprint Planning

As we described in part 1, Essence also presents the key information about an activity through a poker-sized card. Figure 90 shows a Sprint Planning activity card.

Figure 90       Sprint Planning activity card with template

Smith’s team started using Scrum on top of Essence on one Monday morning with Sprint Planning. This was all about deciding what priority items from the Product Backlog should go into the current Sprint Backlog.

But it was about more than just picking items from the Product Backlog and moving them to the Sprint Backlog. It was also about the team asking some critical questions such as:

  • “Were the items selected for this sprint properly prepared?” Properly prepared means that the items are broken down into small enough items that can be completed by the team within the time available in the next sprint.  This means there must be enough information about each selected backlog item for the team to estimate the effort to complete it. You might be wondering how the team knew to ask this question.  Some of the questions the team asks may come from an explicit practice defined on top of the kernel such as the Sprint Planning activity that is part of the Scrum practice. However, other questions may be based on the kernel itself. For example, note that a Sprint is a sub-alpha to the Essence Work alpha (refer to Figure 81). The Work alpha contains a state named, Prepared. Achieving this state means all pre-conditions for starting the work have been met.  One of the checklists in this state includes; “The work is broken down sufficiently for productive work to start.” This checklist item should remind team members to ask if the backlog items have been properly prepared regardless of the practices they have agreed to use.
  • Another related question is: “Could the developers estimate how much effort it would take to complete each item from the information given in the backlog?” If not, this meant the team needed to go back to the product owner and get more information or reject that item as not being ready to be worked on in the sprint.
  • And another question is: “Has the team considered their capacity when deciding if they could commit to the proposed items to complete in this sprint?” This question comes specifically from the sprint planning activity within the scrum practice. This means each team member needs to consider how much time they have to work on the endeavor and if they believe that is enough time to complete the items the team is committing to complete in the sprint. Note that from Figure 89 we see that the Scrum team has the responsibility to be self-organizing.  This means they are responsible for estimating and committing to the work to be completed within a Sprint. If the team had chosen to use a different practice than Scrum this responsibility might have fallen on a different person, for instance a manager, in the organization. This is because another practice might define its roles differently than Scrum.

The preceding questions provide good rationale why some teams need explicit practices and some don’t. Teams need to ask questions such as:

  • “Are our team members experienced enough to know to ask the preceding questions?” If the team does not have adequate experience they need to decide if other team members can help, or if they need to ask for more help from outside the team. “Do they need explicit reminders, such as checklist reminders to conduct a proper disciplined Sprint Planning session?” The answer to this question often depends on how many people on the team have previous experience conducting sprint planning.  In some cases, explicit practices may be sufficient, but if most or all of the team members are new to Scrum then a coach may also be needed to guide them through their first few sprints.  Explicit practices can provide these critical reminders to teams that have less experienced practitioners or who have never worked together before, but sometimes a coach is needed to properly set the expectations of their new team.  

Both Product Backlog and Sprint Backlog have a simple poker-sized card to describe them. Figure 85 shows a Sprint Backlog work product card, which identifies what a Team agrees to Work on for a sprint. Note that this card can also provide reminders of activities the team should be conducting while producing the work product. For example, the team needs to agree on the goals for the sprint, and it needs to estimate its capacity when it is developing its Sprint Backlog. In the past often there was considerable effort put into producing lengthy documentation that wasn’t used.  This often occurred because practitioners tasked with producing this documentation did not have clear guidance on what should be included, along with how much detail. Work Product cards provide a simple way to communicate what practitioners need to know to produce useful documentation that achieves the intent of the work product.

As mentioned earlier the team’s first target was to work towards a version of the system suitable for internal users. Angela participated as the product owner and she quickly identified a number of product backlog items, as follows in Table 8. 

Table 8           Product Backlog

Item

Product Backlog Item

Originator

Priority

Estimate

1

Set up group of internal users

Angela

High

2

2

Add toggle for recommendations feature based on user group.

Angela

High

1

3

Run series of tests to ensure the toggle for recommendations feature does not result in performance degradation

Angela

High

2

4

Add introductory user screen for recommendation functionality

Angela

Medium

3

5

Develop the pre-processing data needed for the recommendation algorithm.

Smith

Low

5

 

Since Smith’s expertise and background was the technical solutions area, he identified some items on the Product Backlog, focusing on the technical issues. Smith said, “We need to get going on the recommendations and the user screen. These are both high priority items.“ This is not meant to imply that we only need technical issues on the backlog. As we have explained earlier, the Product Backlog should include all work the team has to do from the stakeholders’ perspective. This was all about making the Product Backlog the “single source of truth” for the whole team. Everything that the team might ever need to do would eventually be added to the Product Backlog. However, at this point in the endeavor the Product Backlog was not a complete list. It contained a number of items the team knew they needed to do, but certainly not everything needed to create a new release. This is the way many endeavors get started.

The Product Backlog evolves as the team progresses through the Sprints. The team learns more about what requirements are needed as the endeavor progresses. This is how many endeavors evolve.  The team knew from their previous work with Essence during the internal demo the value of the alpha checklists, especially in regard to helping them get their Work to the Under Control state. As an example, checklists from the Work alpha reminded the team of the need to make sure they had sufficiently broken the work down.  This helped the team confidently estimate the work to fit within its agreed Sprint.

During the Sprint Planning session Joel said, “I don’t think we have enough information to estimate the work involved in Item #2.  Angela, can you explain more about what you mean by the toggle for recommendations based on user group?”  After further discussion, the team felt they understood that all Angela wanted was a way to turn the recommendation on or off for particular user groups. This could be easily achieved by adding only several lines of code to perform this conditional check. Thus, they understood the backlog item well enough to make an estimate (see Table 8).

What we have just described demonstrated how by applying the Sprint Planning activity that is part of the Scrum practice the team members were better able to understand the work products.

15.8.2 Daily Scrum

The Daily Scrum is a simple activity that Scrum teams conduct every day. There are only a few guiding principles required (Figure 91), such as keep the meeting to 15 minutes, only the developers speak and keeping the focus on answering the three main questions (what did I do since the last daily scrum, what do I plan to do next, and what obstacles am I facing).  When conducting the daily scrum Smith’s team met at the same time and same place each day. By keeping the meeting to just 15 minutes it forced Smith’s team members to be as brief as possible, just focusing on answering the three questions. As each team member answered the questions the others listened and if they heard something where they could help they agreed to talk further after the meeting with just a smaller group that needed to be involved in the discussion. In this way team communication was enhanced while minimizing the time lost by all team members in attending the meeting. When someone identified an obstacle that was keeping them from getting their work done, Smith, the scrum master, accepted an action to work the issue, but sometimes other team members stepped up and helped when they knew how to solve the problem. But they didn’t discuss the solution in the daily scrum because they didn’t want to take up the time of the other team members who didn’t need to be involved in solving the problem.  The daily scrum helps the team keep the Work Under Control.  In Figure 91 at the bottom of the card the result of the activity is that the Work alpha will be in the Under Control state. Since no state was specified as input to the activity it means that the daily scrum is done in the same state.

Figure 91       The Daily Scrum activity card

In our TravelEssence endeavor, during the daily scrum Tom said, “I have been working since our last daily scrum on item #4, the introductory user screen, and I am having some trouble getting it to work.” Joel replied, “Tom, I have worked on introductory user screens before so I will give you some help right after the daily scrum.” From an Essence perspective, we can see from Joel’s reply how their daily scrum is helping to progress the Team Alpha, Collaborating state, checklist items. As examples, “The team is working as one cohesive unit,” and “Communication within the team is open and honest”.

The value in documenting these simple guidelines for a daily scrum as checklist items in an activity is that they serve as reminders to the team that can help them consistently conduct the daily scrum. These checklists items can be used during training and coaching sessions. They are also useful for bringing new hires on board. 

15.8.3 Sprint Review

The sprint review is a review of the product by the stakeholders (see Figure 92).  The focus of this review should be on demonstrating what the team produced based on what they committed to produce at the previous sprint planning session.  Angela, as the product owner, led this meeting, but she was supported by the other team members who worked the changes related to the current sprint.  To keep the meeting focused Angela started each review by going over the sprint backlog items that the team agreed to work on during the previous sprint. Then each item was demonstrated and Angela then asked the stakeholders in attendance if they agreed that each sprint backlog item that was committed to was achieved. Only sprint backlog items that were completed during the sprint were demonstrated. If something was partially completed its demonstration was put off until the next sprint when it could be fully demonstrated.  Scrum teams do not take “partial credit” for completing part of a backlog item.  If committed sprint backlog items are not completed the product owner explains this during the sprint review and explains the plan to address the missing item. The sprint review is also an opportunity for the team members to get valuable feedback from the stakeholders. This occurs primarily at the end of the sprint review when the product owner asks the stakeholders if they feel that the goal of the sprint was achieved.  However, often stakeholders provide feedback throughout the review. In this case at the end of the sprint review the product owner summarizes the result of the review and the actions the team is taking out of the review to address in a future sprint review. Input to the review is the product backlog that is used to ensure the review focuses on the items the team committed to complete. The card also shows that Sprint alpha is in the Planned state prior to the Sprint Review activity and is progressed to the Reviewed state as an output of a successful review.  Moreover, it shows that the increment work product is updated with new product backlog items as an output of the review.

Figure 92       The Sprint Review activity card

Often when Scrum teams operate with only tacit practices the Sprint Review can lose its focus with stakeholders bringing up issues that were never planned as part of the sprint, or team members discussing the method they are following rather than the product they have produced.  The value in adding a simple Sprint Review activity, or at least adding checklists, is that these checklist reminders can help the team to recall their agreed to activities related to the sprint review. It can also help to bring new people on board similar to what we just discussed with the Daily Scrum.

In our TravelEssence case when it came time on Friday for the sprint review, Angela, as the product owner, led the meeting.  She started out the review, by explaining to the stakeholders who came to the review (Cheryl and Dave, since this sprint was focused on an internal release) the product backlog items that the team had committed to for this sprint, and what they were going to see demonstrated. Angela then asked Grace, Tom and Joel to demonstrate what they had accomplished during the sprint.  At the conclusion of the sprint review, Angela explained how they had not been able to fully implement the user screen because they ran into a few issues, but they felt they did meet their commitments for achieving the toggle for recommendations. 

Cheryl then asked the stakeholders in attendance for their feedback, and if they thought the goal of the sprint had been achieved. It is worth noting that often explicit practices and their associated activities can help teams progress multiple Essence alphas at the same time.  For example, the Sprint Review activity just discussed, as part of our Scrum Lite practice, helps the team progress the Essence Stakeholder Alpha, Involved state, checklist item, “The stakeholder representatives provide feedback and take part in decision making in a timely manner.”  This can be seen in our TravelEssence case with the involvement and feedback provided at the sprint review by our stakeholders Cheryl and Dave. As another example, we can also observe from the sprint review activity how the Essence Work alpha, Under Control State, checklist item, “Estimates are revised to reflect the team performance” and “Measures are available to show progress and velocity“ are achieved from the team’s discussion with the stakeholders on the issues they encountered and the tasks they successfully completed.  

15.8.4 Sprint Retrospective

The purpose of a sprint retrospective is for the team to review how they are doing on their endeavor from the perspective of their agreed to method, and to agree to improvements to their method to do in the next sprint. The results of these improvements can be tacit or explicit, which means they may or may not require changes to practice descriptions.

There are many techniques available for conducting sprint retrospectives. There are even books that have been written just focused on this subject alone [15]. The value of the Sprint Retrospective is to get feedback from your development team on what is working well and what isn’t working well, and get agreement with the team on what they can do differently during the next sprint to improve their method (see Figure 93). The Sprint Retrospective can also help to guide teams with decisions related to how to move forward with the team’s suggested improvements. 

Figure 93       The Sprint Retrospective activity card.

A Sprint Retrospective could be represented in the Essence language as an activity within a larger practice, such as Scrum, or as a practice itself. For example, many organizations break their retrospectives out as a separate practice and include in the practice criteria to help teams select practical improvements that can be implemented within the next sprint.  An example of such criteria are referred to as the SMART criteria, which stands for Small, Measurable, Attainable, Relevant, and Testable. These attributes are intended to be used by teams to help them assess if their agreed to improvements can be implemented within the next sprint.  For instance, a team member could ask the following questions in regard to a proposed improvement:

  • Is this improvement small enough for the team to implement it the next sprint?
  • Is this improvement attainable?  If all the team members do not have the needed skills to implement the improvement then it might not be attainable. 
  • Is the improvement relevant? There are lots of improvements that teams could decide to make that might not be relevant to helping the team achieve their goal.
  • Is the improvement testable? We need to know how we are going to test the improvement to say whether we achieved it or not. 

In our TravelEssence case Smith started the sprint retrospective by asking all the team members to jot down on yellow sticky notes things they thought went well during the sprint and things they thought didn’t go well and could be improved. Smith then collected all sticky notes and grouped the ones that seemed to be related under larger sticky notes that said “working well” and “not working well”. He then highlighted to the team that everyone felt the team was working well with respect to communication.  It is a good idea to always start a sprint retrospective by sharing with the team what is working well so the team doesn’t feel like they are always just focusing on negative things.  Smith then move over to where he had grouped a number of yellow sticky notes under the heading “not working well.” He pointed out that a number of team members felt that the team could do better in future sprint planning sessions. 

Smith said, “Grace, one of your sticky notes says ‘sprint tasks unclear’. Could you explain what you mean by that? Grace replied, “Sure. I don’t think we are breaking our sprint tasks down enough and describing enough about what needs to be done to complete each task.” The team then used the Essence Work alpha, Started state, checklist item, “The work is being broken down into actionable work items with clear definition of done,” to stimulate their retrospective discussion related to breaking work down. Tom said, “I agree with you Grace. I think we need to spend a little more time discussing and agreeing what ‘done’ means for each of our tasks before we commit to the sprint work.”  The team agreed that this would be an improvement area they would work on during the next sprint. Specifically, they made it a point to break down the work into items each with clear acceptance criteria. This was one of the reasons why they move to user stories, which we will be introducing in chapter 16.

15.9 Reflecting on the Use of Scrum with Essence

As we saw in part 2, Essence by itself can help teams who are experienced, or are working on a simple endeavor where their practices are tacit (i.e. not written down).  When your endeavor is more complex or more people are involved who have never worked together, then there is increased risk of miscommunication of what activities the team members are expected to carry out and the degree of detail expected in work products produced.  There is also increased risk that different team members will assess their progress and risks differently leading to confusion and inaccurate progress reporting to stakeholders. 

15.9.1 Adding Explicit Practices

Scrum essentialization helps you to focus on the essentials of Scrum in two important ways:

  1. Calling out the most important parts of the practice.
  2. Making explicit what these important parts are.

For example, there are many books written about Scrum, but how do you explain Scrum quickly to a team new to Scrum? You will inevitably need to choose what to talk about and what to ignore. It is worth repeating that in this chapter, we have done that and we call what we want to talk about Scrum Lite. Next, you have to describe the result in a way that is easy to understand and not misinterpreted by the team. We do that by essentializing Scrum Lite. Recall that when we use the term “essentialized” we mean you have described your practice using the Essence kernel and language.

Thus, an essentialized Scrum Lite can provide guidance in the essentials of conducting certain activities such as Sprint Retrospective and Sprint Review. There are many different ways teams can conduct a sprint retrospective [15] that goes beyond what is essential. As an example, they can ask each team member to write down what went well, and what didn’t go well during the last sprint. This helps the team decide where they can improve for the next sprint.

15.9.2 Visualizing the Impact of the Scrum Lite Practice

Let’s see how essentialization helps teams see more clearly where gaps exist in their own practices using the Essence kernel as a reference. This leads them to see where specific new explicit practices may be needed or improvements to their existing explicit practices.

To demonstrate what we mean, Figure 94 shows all the activity spaces in the endeavor area of concern. It also shows the activity spaces that are populated by Scrum Lite activities. Note that Sprint Planning activity occupies two activity spaces, namely: Prepare to do the Work, and Coordinate Activity. The sprint planning has the dual purpose of creating an initial product backlog and a sprint backlog from which the team can start working, and iteratively update the product and sprint backlog to keep the team going.

Figure 94       Endeavor activity spaces partially filled with Scrum Lite activities

As can be seen Scrum Lite only occupies four out of the five activity spaces in the endeavor area of concern. In particular, “Stop the Work” is empty. This activity space is about concluding the work. These are outside the scope of the Scrum Lite practice and thus show the team where they have gaps.

Figure 95       Solution activity spaces (not addressed by Scrum Lite)

Scrum Lite (and Scrum as well) also do not provide any guidance on other areas of concerns, (i.e. the customer and solution area). As an example, Smith and his team did have issues with how to work effectively with regards to activities in the solution area of concern (see Figure 95) and hence needed some explicit guidance. For example, in our TravelEssence case, the team quickly observed gaps in their requirements practice leading them to apply User Stories Lite, and then Use Cases Lite.  We have included an  exercise at the end of this part of the book for students to extend the TravelEssence case to demonstrate other possible gaps in practices related to the other Solution activity spaces referenced in Figure 95. 

15.9.3 Value of Being Precise

The idea of practices is not new. It has been around for maybe 50 years.  In the past, we have seen two major problems.  Firstly, practices have been applied in an ad hoc manner. Sometimes different authors use different words to mean the same thing. Or perhaps, a single word has more than one meaning, or two words may overlap, but have some violent disagreement at the same time. To practitioners, it meant that he/she had to relearn the vocabulary when moving from working with one practice to working with another. What the Essence standard attempts to do is to eradicate this kind of unnecessary confusion. The second problem is that sometimes practices and methods are too rigorous. For example, some quite successful methods were described on thousands of pages. The intention was good, but it didn’t work in practice. There is a law of nature: “Most people don’t read big books”. Thus when developing Essence the following points were considered for how individuals in the team/organization should learn and improve:

  1. Focus on the essentials. This is the gist of a practice, maybe 5% of what an expert knows of the practice but enough to participate in a team.
  2. Use a very simple intuitive visual language to describe guidance of practices, alphas, activities, etc.
  3. Provide a simple way to access additional guidelines, for example using links to books, teaching materials and tools from the essentials.
  4. Keep practices separate but make them composable with other practices to form methods.
  5. Keep the practices in a library and let the teams that develop software improve them easily and quickly when they do retrospectives.

Regarding the first three points above, what has been done is to be precise and explicit, and to give the essentials a certain level of rigor using the Essence language. The goal is to facilitate more effective communications and guidance, so that team members can have more time to do the actual work.

This precision is made possible not only through the language and its usage but also by focusing on the essentials. Thus, practice descriptions following this approach are very concise and intuitive to practitioners. It serves as a reminder, and help teams get started with conversations. The Scrum Lite practice is just 12 cards (see Figure 96), one card for each element in Figure 80 in section 15.3.

Figure 96       Scrum Lite as a deck of 12 cards

With an understanding of the Essence kernel as presented in part 2, a practitioner only needs to have just a small deck of 12 cards to begin his/her journey understanding, learning and applying a new practice. If you want to give more guidance to the practitioners, more detailed descriptions can be made available. Associated with each card there could be a 2-4 page document with further details, guidance, hints, tips and common mistakes. All the cards mentioned in this book are available for download on the book website at http://semat.org/web/book/.

Regarding the last two points above, Essence provides a mechanism for teams to select and compose practices. Our work with practices have yielded a sizeable set of practices.We will discuss this further in part 4 of the book, when we talk about how Essence can scale to large organizations.

So, our recommendation to software engineering students is to learn the kernel, learn the language, symbols, and agreed terms, to lay the foundation for learning and comparing the multitude of practices in software engineering. In the remainder of this part of the book, we will demonstrate how Smith’s team - with the help of precise and explicit practices - embarked on their journey to successful software delivery and personal growth.