Author Archives: Craeg Strong

About the Customer

Samsung is a global leader in electronics, information technology, and telecommunications, headquartered in Seoul, South Korea. With over 290,000 employees worldwide, the company operates in more than 80 countries, innovating across industries including mobile devices, semiconductors, home appliances, and network infrastructure. Known for its commitment to cutting-edge technology and customer satisfaction, Samsung continues to drive advancements in product development, artificial intelligence, and IoT applications.

Industry: Electronics, IT, & Telecom

Headquarters: Seoul, South Korea

Employees: 290,000 +

Atlassian Products Used

Jira Software: A suite of agile work management solutions that powers collaboration across all teams from concept to customer.

Jira Service Management: A high-velocity IT service management solution that empowers teams to deliver exceptional service experiences quickly and efficiently.

Atlassian Confluence: A team workspace where knowledge and collaboration meet, helping teams create, share, and organize content effortlessly to drive productivity.


Other Applications Used

BMC RemedyForce: A service management solution integrated into Salesforce


The Challenge

Samsung’s IT infrastructure faced significant operational challenges, which prevented them from efficiently handling service requests and incidents. Their use of Jira Software (JS) for service management tasks created bottlenecks, as this setup lacked the service-oriented features they required for managing requests, incidents, and change approvals. Over time, treating service requests like software development tasks in Jira Software created inefficiencies, with requests left in backlogs, agents unaware of urgent requests, and critical information not reaching approvers in a timely manner. The absence of a dedicated service platform increased overall resolution times and led to a decline in user satisfaction.

Ariel Partners stepped in to address Samsung’s specific needs, proposing a comprehensive migration from Jira Software projects to Jira Service Management (JSM) projects, thereby enabling a fully integrated service management solution to address key challenges.


Project Requirements

Migrate Jira Software projects to Jira Service Management with minimal downtime

Set up accurate ticket routing to direct requests to the appropriate teams and agents

Establish a customer portal allowing request submissions without individual licenses

Integrate JSM with RemedyForce to maintain continuity with Samsung’s existing infrastructure

Configure SLAs to ensure timely responses and resolutions with automated escalations

Implement a self-service knowledge base within the JSM portal using Confluence


The Solution

Ariel Partners implemented a custom Jira Service Management (JSM) solution, transforming Samsung’s service management operations. The project involved migrating selected Jira Software projects to JSM to provide a centralized platform for service requests, incidents, and change requests. A key step was configuring a JSM customer portal that allowed users to submit requests without a license, saving Samsung significant costs. Ariel Partners also developed service-level agreements (SLAs) and automated escalation protocols to ensure timely ticket handling, preventing delays and minimizing backlog issues.

Atlassian Confluence was integrated as a knowledge base so users could access self-service resources within the portal. Ariel Partners further integrated JSM with Samsung’s RemedyForce platform, ensuring that Samsung’s teams could continue using RemedyForce while benefiting from JSM’s advanced service management capabilities.


The Results

Cost Savings: License-free request submission reduced user licensing costs

Efficient Ticket Routing: Tickets automatically reached the correct teams or approvers

Higher User Satisfaction: Users had visibility into ticket progress via the JSM portal

Seamless Integration: RemedyForce and JSM integration maintained continuity

Timely Resolution: SLAs ensured tickets moved efficiently, reducing backlog

Increased Self-Service: The Confluence knowledge base reduced ticket volumes


Why Ariel Partners?

Ariel Partners is a premier provider of Digital Services, Software Development, Coaching, Training, and Management Consulting. With special expertise in Agile methods, DevSecOps, Human-Centric Design, and the Atlassian suite, we deliver transformative solutions to both commercial and federal clients. Our team includes certified experts across AWS/Azure Cloud, Agile frameworks, Kanban, SAFe, LeSS, ITIL, Cyber Security, and Project Management. We hold a Top-Secret Facility Clearance and are appraised at maturity level three by CMMI for Development and Services, while also certified ISO 20000, ISO 27001, and ISO 9001 compliant.

As an Atlassian Silver Partner and Certified Government Partner, Ariel supports global leaders like Samsung and federal agencies such as the U.S. Air Force with a range of services, from Atlassian product resale and integration to custom training and managed services. Ariel has provided Jira training for 1,200 people within the Business Services Directorate of the US Air Force Lifecycle Management Center. Ariel Partners is committed to empowering organizations to meet their most critical missions through innovation and sustainable change.


Additional Atlassian Products

Ariel Partners is an Atlassian software reseller of the entire suite of Atlassian products, including Jira Software, Confluence, Jira Service Management, Jira Align, Bitbucket, Bamboo, and Fisheye, for both, data center and cloud instances . We are capable of reselling, administering, training, and supporting the entire Atlassian suite, as illustrated below:

1.0 Introduction

Over the last two years, the Covid pandemic has forced state and local governments throughout the US to scramble to support a fully remote work environment. Supporting a fully remote work force requires comprehensive changes touching every aspect of IT, including cybersecurity, networks, workflows, tools, Agile practices, operating platforms, governance, and oversight.
The scope of these dramatic changes has been especially challenging for state and local governments, given the fact that many were still early in their adoption of cloud technologies, and most required their IT teams to work co-located and on-site at all times. It is a cruel irony that many state and local governments that had begun their adoption of Agile methods may have needed to work even harder to adapt to the new remote reality. How can smaller teams continue to work closely together, collaborating heavily with lightweight tools like whiteboards and sticky notes? Even now that the pandemic is in its later stages, hybrid remote work seems here to stay. Fortunately, Agile teams have found ways to adapt to the challenges of remote work, leveraging the strengths of capable tools such as the Atlassian suite and modifying Agile practices to suit the new realities. While it is true that some of the benefits of in-person agile collaboration are lost in a hybrid remote work environment, there have also been some gains. This paper will describe how one project adapted to working in a 100% remote environment, successfully delivering an extremely challenging IT solution against all odds.

2.0 Adapting to Remote Work

Attempting to use Agile methods for a fully remote team poses a number of challenges such as defining and managing requirements, maintaining quality, and sustaining motivation and engagement. The main challenge underlying all of these is maintaining a high degree of collaboration. In our particular situation, some of the team members worked in different time zones, further exacerbating this problem.

As long-time users of the Atlassian suite of products (Jira Cloud, Confluence Cloud, Trello, and BitBucket Cloud) we were better prepared than most for this challenge. In general, Agile Lifecycle Management (ALM) tools have improved significantly over the last five years, and that is more than evident in the Atlassian suite. Atlassian’s tools have gotten more capable, new offerings have been added, and the third-party plugin marketplace has burgeoned spectacularly. The pandemic has spurred a wave of incredible innovation that has changed the game. For a long time, software tools struggled to match the flexibility of a plain-Jane physical whiteboard with sticky notes—but were useful for reporting and auditing. Now, we we are quickly closing in on a time where electronic tools will meet and even exceed physical workflow systems in nearly every respect.
Below is a list of practices that we used to facilitate our Agile work of our remote team. We established some of the practices up front, others evolved over time, and some were happy accidents or the results of trial-and-error experimentation. We will discuss each in turn:

1. Establishing core hours
2. Longer standup meetings to limit the number of interruptions during the day
3. Always keeping camera on during virtual meetings
4. Heavy use of a team Slack channel
5. Cloud git repository with cloud-based CI/CD, integrated with Slack
6. Expanded usage of our Confluence team space
7. Easy Agile Story Mapping Plugin
8. Jira conventions: daily comments, recording collaborators

2.1 Core Hours

The concept of establishing a set of core hours where everyone must be online is not a new one, and many teams had established these prior to the pandemic. However, while working remote we found this practice to be essential. We established a 5-hour period where all team members agreed to be online, including both west coast and east coast-based personnel. Although we never tried it, we suspect that having less than a 4-hour overlap could have a significant negative impact on most Agile teams. We would love to hear from teams that have managed to be successful without establishing core hours.

2.2 “Longer” Standups

Our team used the Scrum Agile method, with many Kanban practices sprinkled in (this is sometimes known as Scrumban). One of the key Agile practices recommended by both Kanban and Scrum methods, is that of the short daily standup. Like all Agile teams, we strived to complete our daily standups quickly, say in 15 minutes or less. However, we found that technical discussions emerged out of our standup on a regular basis, and soon it was a daily occurrence. Agile coaches will recognize this as a common pitfall for Agile teams, and we at first assumed the same thing and attempted to steer the team to closure. However, when we analyzed what was happening more deeply during a retrospective, we discovered that the team preferred to combine the standup with their technical discussions in order to have fewer interruptions during the day. Our team found online meetings to be more intensive and therefore disruptive than the type of casual water cooler conversations that are commonplace for co-located teams.
We discovered that, while team members would still meet with each other over MS Teams as needed, they had come to rely on the fact that everyone would be online simultaneously during the standup, so it would be easy to simply extend that standing meeting. By using this time slot, there was no need to create a calendar invite, coordinate schedules, etc. Team members indicated that they found the longer daily meeting to be convenient—that is, the benefits were high relative to the cost.
In order to accommodate this strategy, we simply extended the calendar invite for the daily standup to a full hour each day, and it became two meetings in one. On some days there was no need for the after-meeting, so we simply ended early. It is important to note that we did not actually extend the daily standup itself—we generally completed it quickly, but then seamlessly jumped into technical discussions. In fact, we found that the fact that the team expected a technical discussion to take place every day immediately after the standup actually helped us get through the standup even more quickly, since there was no fear that some technical point would be missed.

2.3 Camera On!

In order to increase engagement, each team member agreed to turn their laptop camera on during every online meeting. We recorded this in the team’s working agreement, documented in Confluence. We agreed to a protocol that if an emergency arises (package delivery, baby crying, etc.) that turning the camera off is an indication that one has stepped away. We all agreed in this case to turn the camera back on as soon as the situation in question is addressed.

2.4 Team Slack Channel

Many commercial software development and support teams have been using Slack for years, but it is relatively new for government. Knowing that we were going to be working remotely, we configured a slack channel for the team from day one— and we have never regretted it. Slack channels have many benefits. They enable team members to communicate continually without breaking concentration. Slack users are socialized not to expect an instantaneous response. Yet, unlike email, it is easy to resume the thread of a discussion hours later without losing context. We created a separate slack channel for messages from our CI/CD pipeline. We didn’t want those to clutter up our team channel, and yet we needed everyone to be aware of the progress represented by the builds that were executing and to be able to respond immediately if the build was broken. Each build message included a link to view automated test results. This practice is one we will carry over to all teams regardless of co-location or remote status.

2.5 Cloud-Based CI/CD via BitBucket Pipelines

Given the magnitude and uncertainty of the technical challenge before us, we knew we would need an automated build, continuous integration, and continuous deployment capability. On the other hand, we dreaded the prospect of logging into the Agency VPN, setting up Jenkins pipelines and troubleshooting the inevitable problems. Fortunately, we were able to use Bitbucket Cloud instead. We configured a few BitBucket pipelines to automate our builds, run tests, and generate test reports. All builds were kicked off automatically both in the main branch as well as pull request branches. Each build generated a slack message that contained a link to view the build results and test reports. This setup was transformative. None of the team members could remember a more seamless, trouble-free DevSecOps experience. I, for one, will not be going back to Jenkins anytime soon.

2.6 Increased Usage of Confluence

We set up a Confluence space for our team, as is customary for our organization. However, we found that the remote environment encouraged us to use our team space much more than before. Keeping the team contact sheet up to date was paramount. Everyone added their mobile number and time zone so we could track time differences. Here is a list of some of the capabilities we used:

Meeting notes template
We captured action items and aggregated them. Confluence macros automatically aggregated all of the action items on every child page and summarized them. We captured names and titles of everyone who attended each meeting and made sure to capture all key decisions. Team members and government stakeholders alike found these very helpful, and we referred to them often to understand which technical questions had been answered and which were still outstanding.

Agile cadences
We created a page for each cadence where we indicated any adjustments or customizations we made. We added a page for Backlog Refinement, Sprint Planning, Daily Standup, Sprint Review, Retrospective, and Team Working Agreements. We used Ken Rubin’s excellent Visual AGILExicon graphics which are available for free from here: https://innolution.com/resources/val-home-page

Risk List
We created a risk list and maintained it in our Confluence team space.

HOWTO articles
We captured HOWTO articles for common challenges such as fixing up git when it spits up.

Glossary
Anytime a team member encountered an unfamiliar word or acronym (both business and technical) we would place them in the glossary, whether or not we knew the definition. Team members would occasionally browse the glossary and add in definitions, wikipedia style. There are probably still a few not yet defined!

Questions and Answers
Many of our government SMEs were not able to meet with us very often. We have seen this affliction spell doom for several Agile teams. Our approach was to capture all of our questions in Confluence so we could rapidly go through all of them when we did get precious face time with the SMEs. While we still had a few situations where we had to make assumptions while waiting for answers, we were able to adapt quickly to those situations by keeping the code base clean and easy to refactor. We maintained QnA lists by date so the government could easily refer back to exactly what they answered and when. This was particularly helpful to the team when the government changed its mind on a few items. Rather than assigning blame or arguing about who was right, we simply acknowledged that things had changed (our team was one of many interdependent teams running in parallel) and got down to work and did what needed to be done. The government appreciated the team’s flexibility and that served to build trust.

Design documentation
We captured designs and architectural discussions here. The content from our informal Confluence pages eventually made its way into formal documentation to fulfill government lifecycle management requirements for formal design artifacts. Having the notes, sketches, and in progress information available was invaluable to the technical writers who had to eventually produce the baselined documents, and we found that they were also very helpful when we had questions or needed interim clarifications from our government stakeholders.

2.7 Story Mapping All the Time

We found that the Easy Agile story mapping Jira plugin, which we have long used for backlog grooming, became our go-to visualization board for any kind of impromptu planning, sprint planning, or design discussion. The team found the tool so convenient that we ended up using it several times a week. The key feature of the story map is that it provides a richer, two-dimensional view of the backlog, arranging stories alongside their Epics. By arranging the Epics to match their temporal order with respect to one of the main use cases, a story map helps find missing pieces, duplicates, and facilitates adding new enhancements in just the right place. The tool maintains 100% synchronization with the other backlog and Agile board views, and it is rock solid. Perhaps the most important feature of the Easy Agile story map plugin is the way it enables an analyst to add new user story candidates as fast as a government SME can describe them. As long as you have a reasonably good typist on the team, this tool virtually eliminates the need for taking separate notes, capturing voice memos, or using other tools that require someone to transcribe/translate them to Jira as a second step. In 20 years of software development, this is the very first tool I found that can do this, and it is a game changer. The Easy Agile tool was our constant companion, enabling us to immediately and seamlessly capture all important information during meetings as team members, analysts, and SMEs came up with ideas, experiments, new features, enhancements, and defects.

The Easy Agile storymap plugin provides a more understandable view of the backlog and a fast and convenient way of creating new work items

2.8 Issue Conventions

Finally, we adopted a few extra conventions for working with Jira issues that we found helpful for remote work. For example, we mandated that every team member must add at least one small comment to every issue they were working on each day. That way, even if nothing changed, the team would never be left in the dark if a given team member was out sick or otherwise unavailable.

To further encourage collaboration and ensure the Agile board accurately reflected what each of us was doing, we added a custom “Collaborators” field and recorded everyone working on each card in that field. We customized the Agile board to display the Collaborators field so that all applicable team members were displayed, not just the assignee. With this in place, the choice of whether someone was actually assigned to a card versus added as a collaborator became more or less just a formality.

3.0 Conclusion

Using the techniques described above, our remote team was able to successfully deliver a complex piece of new software. Moving to a fully remote posture required a few tweaks to our Agile practices, as well as a few customizations, conventions, configurations, and 3^rd party tools. All in all, this demonstrates how the Atlassian suite forms an essential part of enabling hybrid and remote teams to deliver successful outcomes using Agile methods, without skipping a beat.

4.0 About Ariel

Ariel is an IT Services, Training, and Management Consulting firm with special expertise in Atlassian products, Enterprise Architecture, Big Data, DevSecOps, cloud-based microservices, web and mobile app development, AI/ML, Agile, and Human Centered Design. We are an NWBOC-Certified Woman Owned Small Business (WOSB) founded in 2010. We provide IT services to Federal Agencies and Commercial clients to help them transform their systems and, more importantly, their method of delivery. Our staff includes experts with Professional Certifications for Atlassian products, AWS/Azure Cloud, Agile, Scrum, Kanban, SAFe, LeSS, ITIL, Cyber Security, and Project Management. We currently hold a Top-Secret Facility Clearance. Ariel Partners is appraised at maturity level three by CMMI for both Development and Services and is certified ISO 9001:2015, ISO 20000:2018, and ISO 27000:2013 compliant. Ariel is an Atlassian Silver Partner, Certified Training Partner & Certified Government Partner, and is a certified Scaled Agile, ICAgile, Flight Levels, and Kanban University training facility.

Ariel provides critical support to a diverse set of large Agencies and institutions. Ariel is 100% committed to helping our customers achieve their mission objectives

Ariel has deep experience executing large systems development and implementation projects for Federal agencies and other organizations including the FBI and NYC Department of Social Services. Ariel has provided project management, business analysis, systems engineering, testing, and support services for system implementations up to $500M in size, spanning all 50 municipal Agencies in NYC, and for FBI programs used in all 50 states and in Interpol countries spanning the globe. We led the 2nd program at FBI to move from waterfall to Agile. We established a large-scale Agile governance and oversight framework for the Social Security Administration, assessing more than $500M of mission critical programs. We have worked with the DOJ/FBI since 2003 on mission-oriented programs including NCIC and CODIS and have helped them institute major new programs and initiatives including Missing Persons, Rapid DNA, and NCIC Third Generation (N3G). We have provided public training classes in Kanban, SAFe, Jira, and HCD since 2016.

Ariel has a wide range of offerings to help our customers get started with Agile or turbo-charge their Agile implementation. Our Jira offerings include a “Jira Jumpstart,” which bundles a set of Atlassian product licenses with configuration, training, and coaching to get an organization up and running immediately or elevate their existing Atlassian investment up to the next level.

Ariel provides comprehensive Atlassian coaching, configuration, training, and consulting support

1.0 Abstract

This paper illustrates the Jira configurations, processes, tips, and tricks we developed while supporting a large Department of Defense customer that was migrating to Atlassian Jira to support their adoption of Agile and DevSecOps principles and practices.  Rather than providing an Agile transformation how-to recipe, we will describe some of the configurations, templates, processes, and systems we have helped our DoD client establish and the benefits that were observed.  We will cover tips and tricks we used to help make the Jira experience amazing for teams of any variety. We will cover several scenarios such as supporting a large heterogeneous organization, scaling up to larger efforts, how to supercharge daily standups, enforcing governance, and finding better ways of doing backlog refinement.  

Our Jira consulting practice focuses on properly configuring the tool and leveraging the extensive third-party ecosystem of plugins to best support the organization’s emerging Agile processes.  Rather than simply setting up Jira for the DoD and calling it a day, we focused on education, ensuring that the customer was able to configure and maintain their Atlassian products over the long term.  This avoids a common pitfall we have seen for organizations that are new to Jira.  A poorly tuned Jira is a daily struggle for Agile teams.  Inconsistencies in Jira usage and configurations produce unreliable data that limit an organization’s ability to properly manage Agile projects from the team level to the executive level.  Lacking an appropriate level of investment and understanding, Jira can become little more than an expensive task tracking tool, rather than something that can help catalyze improvements and drive organizational change.  In order to derive the maximum possible benefit from their investment in Atlassian products, organizations must appreciate the complexity and sophistication of these tools and assign an appropriate level of investment – both initial and on an ongoing basis.  This involves three main steps:

1. design a set of initial templates, taxonomies, configurations, and reporting metrics,
2. establish roles and responsibilities for Jira administration,
3. and initiate a process of continuous improvement that welcomes configuration changes rather than discourages them.

This paper describes how we performed these tasks for our DoD customer, leaving them with a well-tuned Jira instance, leading to happier, more productive teams, and much more accurate information to make business decisions.

2.0 Background

A directorate within the Department of Defense is undergoing an ambitious transformation effort to roll out Agile methods and tools across their entire operation, in an effort to improve quality and decrease time to market (“faster, better, cheaper”).  The directorate is new to Agile and Jira, and among their personnel there is a wide range of experience levels with both.  The mission of this DoD directorate is to provide logistical support via software systems that manage information such as maintenance, materiel, supplies, suppliers, and readiness at bases and forward locations across the globe.  The directorate is distributed across a number of physical locations and characterized by large, complex bespoke software applications that are integrated with those of several other branches of the armed forces, financial institutions, and both civilian and military Agencies.   The directorate spends more than $1B annually on software operations, maintenance, and development.  It has a staff of 2,000 personnel distributed across four US states and supports nearly 150 programs for tens of thousands of stakeholders within more than 80 large organizations.

The complexity, diversity, and age of the software systems, the large size of the maintenance teams, the number of dependencies and integrations, and the need for transparency and traceability all the way up to the senior leadership level, all served to make the prospect of establishing Agile practices extremely daunting.  Agile methods were initially intended for small, co-located teams of a dozen or less, developing brand new software from scratch, with direct involvement and constant communication with their customers.  When Jira was originally designed for software development, it was  intended to operate in this kind of small-scale Agile environment, utilizing a plugin called Green Hopper.  Most Agile coaches and practitioners operate in this sort of environment and relatively few have experience applying Agile methods outside of this comfort zone.  

Fortunately, over the last five years, Atlassian Jira has grown exponentially more capable, both through the introduction of new features as well as the availability of hundreds of high-quality plugins available through the third party Atlassian Marketplace.  In addition, recent years have witnessed the development of new Agile frameworks, additional tools and practices, and extensions to existing tools and methods designed to be applied at scale and outside of pure IT settings.  Ariel leveraged these new developments to help the directorate create a set of configurations optimized for both flexibility and governance, establish Agile practices supported by matching Jira workflows, and train practitioners and administrators to maintain and continuously improve Jira over time.

3.0 Approach

3.1 Jira’s Configuration Philosophy

One of the core features of Jira is its configurability.  It was designed and built from the ground up to support the needs of large diverse organizations.   The design of Jira projects and Agile boards make it straightforward to support multiple usages, including scaling up a single project across multiple teams, using separate discovery and delivery boards, value stream coordination boards (usually multi-project), and strategy-level boards.

The central metaphors for Jira are the project and the Agile board.  A Jira project is a repository for issues, each of which represent a unit of work (e.g., story, claim, loan, initiative, investment, order).  An Agile board is simply a visual view of a workflow for multiple issues mapped onto a canvas of vertical columns and horizontal swim lanes.  Jira’s Agile boards can support Kanban or Scrum teams, and there is a one-to-one, one-to-many, or many-to-one relationship between projects and Agile boards.  The most typical relationship is one-to-one: where each project has one main Jira board, but multi-board configurations are not uncommon.  

Rather than storing configurations in a single flat space, Jira configurations are split out into multiple schemas.  Projects are configured via associations with these schemas.  This enables projects to share some, all, or none of their configurations with other projects.

By configuring multiple schemes and mapping an organization’s projects to them, a single instance of Jira can support projects with widely different workflows, work item types, and permissions.

Through the use of naming conventions, we can create templates for each of the major project types needed. The main objective is to adopt an initial set of schemes that provide maximal reuse, enabling aggregation of metrics across multiple projects, while still providing as much flexibility as possible.  

3.2 Project Templates

We configured several project templates for the DoD directorate, including Scrum, Scrumban, Kanban, Scaled Scrum, and Legacy O&M, illustrated below:

The Scrum template provides a standard task board with TODO, DOING, and DONE columns.  The team creates sub-tasks and performs story point estimation during sprint planning.  The Agile board tracks the status of each sub-task.  This template cleans up the standard Jira configuration by hiding inappropriate fields and adding a Severity field for bugs.  Non team members do not have permission to do potentially destructive things like creating or closing a Sprint.

The Scrumban and Kanban templates enable teams to do all of their planning at the Story level and capture more workflow steps in the Kanban board (such as “in review” and “ready for acceptance”).  Teams can use checklists to capture details about each Story, and the progress of the checklist items is displayed on the front of the card.  Scrumban uses this Kanban-like approach but adds 2-week sprints, while the Kanban template uses a continuous flow.   This template adds custom fields including “class of service.”

The Scaled template leverages the Scrumban configurations and by convention includes a separate Agile board for each team.  A “Component” is defined for each team, so that assigning an issue to a team simply involves assigning the appropriate Component.  This means we can have our cake and eat it too—there is a single shared backlog for the entire product encompassing all teams, but each team can still easily focus on their own issues via a simple board filter on the Component field.

Legacy O&M teams have special workflow steps, permissions, fields, and screens to handle the extra efforts required to complete items within the legacy environment.

Because the templates support reuse through schemes, we did not have to create separate configurations for every single combination and permutation:

In our training classes, we emphasized that Jira’s configuration schemes are not merely conducive to creating reusable templates, they also greatly facilitate change management.   One of the fundamental Agile principles is to embrace change.  Agile teams are encouraged to make regular experiments to identify process improvements.  Used correctly, Jira’s schema-based configuration design virtually eliminates the risk of change, and greatly reduces the cost of deploying and managing changes.  Jira’s support for evolutionary change is so pervasive and fundamental, that we go so far as to say: No Jira administrator should ever discourage change.  Making changes, applying them selectively, and rolling them back or forward is trivial in Jira.  A separate testing Jira instance is rarely needed.   The below illustrates a typical change management process:

3.3 Administration and Training

While Jira is fundamentally architected for change, none of this will work well without properly trained administrators.  We recommended treating Jira like any other sophisticated enterprise tool, with a sufficiently resourced centralized administration team.  However, we also recommended that each team designate a Jira project administrator to handle team-specific administrative duties.  The team’s project administrator role is not a full-time role, and we suggested that the role should be rotated across team members in order to spread knowledge throughout the team.  Some Jira project administrators may ultimately express a desire to become full-fledged Jira administrators, and this should be encouraged as a career path.  The below illustrates our recommended set of Jira administrative roles and responsibilities.  Perhaps most importantly, Jira administrator roles should require Agile training and certification, in addition to expert Jira knowledge.   

Throughout the course of our DoD contract, nearly a third of all students chose to continue their training past fundamentals and to dive into administrative topics.  In our opinion, this bodes well for the success of the directorate’s transformation.  In our experience, organizations often err on the side of too little training rather than too much.  By supplementing an initial set of Instructor-led training sessions with other types of training we can get better outcomes and a much better overall return on training investment.  For example:

1. Self-service on-demand training videos
2. Remote and in-person Jira coach “office hours”
3. Seminars / brown-bag lunch sessions on tips and tricks, improvements
4. Sample Jira projects for teams to try out templates and improvements

3.4 Supercharging Standups

Now let’s jump over to the configuration of an Agile board in Jira.  A typical scrum team is going to meet in front of the board every day for our standup—so we want the board to be as informative as possible.  In our experience, Jira users rarely take full advantage of Quick Filters.  By adding the Script Runner and Color Cards third party plugins, we are able to colorize the board and enable more sophisticated filter buttons, as in the example below:

In the above example, User stories show up in green, bugs in red, and blocked issues in yellow.  The quick filters help us pinpoint issues we should be focusing on, without having to go to any separate reports.  For example:  

• we can see any issues that are blocked,
• we can see issues that are blocking other issues,   
• we can check to see who the busiest person on the team is—they are probably going to be a bottleneck for us, 
• we can check which cards moved since yesterday,
• stale cards haven’t been touched in a couple days,
• slow cards have been in progress for more than a week—we should aim to complete each story within a week,
• has anything been carried from a previous sprint?  We better make sure we get those done,
• And finally, was anything added after the start of the sprint?  That is a no-no.

The power of Jira’s JQL query language, combined with the Script Runner plugin makes the possibilities virtually limitless.

3.5 Customizing Workflows: Balancing Governance and Flexibility

Jira enables us to set up our workflows to get just the right combination of enforcement and flexibility.  For the DoD directorate, it was important to capture important actions such as approvals in the audit trail.  Fortunately, Jira enables us to set up very flexible workflows that enable users to immediately recover from fat-fingering and other mistakes, while enforcing business rules such as “nothing can be closed normally unless it is approved first.” We demonstrated how workflows could be constructed using global transitions for most status values, and defined transitions into and out of the Approved status.  We defined a Jira transition screen to capture the specific user who granted the approval so this information would be captured properly in the audit trail.  This is because the approver may not be the same person as the one recording the approval in the tool.  The below workflow illustrates the completed workflow design:

3.6 Discovery Board

In our experience, many Scrum teams struggle with the backlog refinement process. Development teams may view backlog refinement as a tedious chore to be minimized.  Teams may struggle to secure time from customers and/or subject matter experts to get their questions answered.  Refinement meetings may spend time discussing items that many of the attendees feel are not relevant to them, or that they feel they lack the understanding to contribute to.  Backlog refinement meetings may struggle from a lack of good facilitation, leading to a few highly vocal participants dominating the conversation while most remain silent.  The result of all of these difficulties is the same—the team performs sprint planning with backlog items that are not well defined, with a significant number of open questions, questionable feasibility, and few or no acceptance criteria.  Low maturity teams may not recognize these problems immediately, with the result that these problems often manifest themselves downstream when defect counts skyrocket.  Fortunately, Scrum teams can turn to Kanban to help solve this problem, and Jira provides excellent support for this.

Jira enables us to create a separate Agile board to help improve our backlog refinement.  This upstream process is often called “discovery Kanban” or “customer Kanban.”  The discovery board codifies a workflow process for backlog refinement that occurs “out of band” from the normal Scrum delivery work.  Some Scrum teams attempt to run this as a parallel Sprint that is one to two Sprints ahead of Delivery (thus ensuring that backlog items are refined just in time), while others simply use Kanban’s minimum WIP limits as warning indicators to drive the process (e.g., ”When we get down to only two soup cans, it is time to order more soup”).  Both the Discovery and the regular Delivery Agile board are available from the Jira “board” menu, and the team can refer to either, as needed.

Below is an example of a Discovery board we set up for our customer.  While we often use card colors to signify work item type in a Delivery board (differentiating user stories from bugs, documents, and tasks, for example), we use color here to differentiate whether or not an Epic has been decomposed into child tasks and stories.  In the example below, Epics that contain child cards are orange, while Epics lacking child cards are displayed in green.  

3.7 Handling Dependencies

One of the most difficult challenges large teams face is how to handle dependencies.  Teams may discover dependencies late in the process, leading to the need to shift gears and interrupt work.  Teams may have dependencies on separate teams or even external stakeholders, leading to delays and conflicting priorities.   Fortunately, we can leverage Jira’s ability to define multiple boards that display different views onto the same underlying data to create an integration board.

For our DoD customer, we created a coordination-level board for a large-scale effort having four teams working on a single product.  The integration board displayed all of the work being done during a sprint by all four teams, grouped by Epic.  For this board, we colored the cards according to the team doing the work.   In this way, it is immediately obvious when two or more teams are working within the same Epic, as in the case of the “Home Page” Epic in the example below.   This board also enables teams to create “reservations,” or slots for upcoming user stories that ensure that another team will reserve capacity in an upcoming sprint for them, thus preventing a dependency from becoming a bottleneck:

3.8 Scaling up

By default, Jira only supports a simple hierarchy of work items, namely Epics and child user stories.  While this hierarchy works well for traditional, small Agile teams, it is insufficient for the larger efforts that our DoD customer needed to support.  Many reports and workflows depend on Jira’s Epic  Story structure, so rather than change that, we simply extend it by adding an additional set of work items linked to each other via the “Implements / is implemented by” link type.

 Using the Structure plugin, we can visualize these higher-level work items as a hierarchical backlog, thereby facilitating our Agile planning processes.  We can also use the coordination-level boards described in section 3.7 to track higher-level work items like Functions and Capabilities as they progress through their own workflow.

4.0 Ariel Jira Jumpstart

Ariel has a wide range of offerings to help our customers get started with Agile or turbo-charge their Agile implementation.  Our Jira offerings include a “Jira Jumpstart,” which bundles a set of Atlassian product licenses with configuration, training, and coaching to get an organization up and running immediately.

5.0 About Ariel

Ariel is an IT Services, Training, and Management Consulting firm with special expertise in Atlassian products, Enterprise Architecture, Big Data, DevSecOps, cloud-based microservices, web and mobile app development, AI/ML, Agile, and Human Centered Design. We are an NWBOC-Certified Woman Owned Small Business (WOSB) founded in 2010. We provide IT services to Federal Agencies and Commercial clients to help them transform their systems and, more importantly, their method of delivery. Our staff includes experts with Professional Certifications for Atlassian products, AWS/Azure Cloud, Agile, Scrum, Kanban, SAFe, LeSS, ITIL, Cyber Security, and Project Management.  We currently hold a Top-Secret Facility Clearance. Ariel Partners is appraised at maturity level three by CMMI for both Development and Services and is certified ISO 9001:2015, ISO 20000:2018, and ISO 27000:2013 compliant.  Ariel is an Atlassian Silver Partner, Certified Training Partner & Certified Government Partner, and is a certified Scaled Agile, ICAgile, Flight Levels, and Kanban University training facility. 

Ariel has deep experience executing large systems development and implementation projects for Federal agencies and other organizations including the FBI and NYC Department of Social Services.  Ariel has provided project management, business analysis, systems engineering, testing, and support services for system implementations up to $500M in size, spanning all 50 municipal Agencies in NYC, and for FBI programs used in all 50 states and in Interpol countries spanning the globe. We led the 2nd program at FBI to move from waterfall to Agile. We established a large-scale Agile governance and oversight framework for the Social Security Administration, assessing more than $500M of mission critical programs.  We have worked with the DOJ/FBI since 2003 on mission-oriented programs including NCIC and CODIS and have helped them institute major new programs and initiatives including Missing Persons, Rapid DNA, and NCIC Third Generation (N3G).  We have provided public training classes in Kanban, SAFe, Jira, and HCD since 2016.  

6.0 Jira Plugins Used

Our DoD customer used Jira Data Center.  Please note that some of the details described above differ for the Jira Cloud product.  The following Jira Data Center plugins were used:

	Third Party App	Where used
1	Easy Agile User Story Maps	User story mapping
2	Actionable Agile Analytics	Actionable Agile Dashboard ReportForecasting with Monte Carlo Simulation
3	eazyBI	Epic Progress ReportCycle Time Per Story Point Set Report
4	Structure	All of the structures for scaling up:Capabilities Structure (hierarchy w/ Capabilities)DMAPS StructureDMAPS Current Release Progress Structure (Showed dependencies as nested issues)
5	Automation for Jira	A resolved Bug closes linked IncidentsAutomatic creation of sub-tasks
6	ScriptRunner	issueFunction JQL Blockers and Cycle Time scripted fields
7	Jira Suite Utilities (JSU)	Clear Field Post-function for Jira workflows
8	Card Colors	Ability to set the color of the entire card in Agile Boards

A couple of weeks ago I was coaching a group of new Jira users. Any time I am working with people new to the tool I always like to provide context along with anti-patterns. If you are not familiar with the term anti-pattern it simply means a common approach to doing something that seems like a good idea, but in the long-run likely won’t work out very well. One of the people in the group said he was copiously writing down the details every time I mentioned one of the anti-patterns and asked if I could put a blog post together with all of them in one place. I said sure, so here it goes…

1. Alienating your Jira admin

Most of the other anti-patterns won’t mean much if you are not on good terms with your Jira administrator(s) since they hold the keys to your Jira kingdom. Their lives can become miserable when every project wants to be customized to the nth degree. Work with them to strike a balance between tailoring to your needs and maintainability on their end

2. Scrum Master Does All The Issue Updates

One of Jira’s strengths is that the entire team can easily contribute. It defeats the purpose of having a tool like Jira if everyone needs to push their updates to a single person just so they can update the issues. Your SM has far more valuable things they can be helping the team with than updating issues. Every team member should be responsible for updating their work in Jira.

3. Not updating your issues at least once/day

It’s hard to trust information if you are concerned it may be stale. Being lazy about updates is a slippery slope. The staler it gets the less concerned everyone is about keeping their stuff up to date. Updating your issues takes no more than a minute or two. If everyone updates their issues at least once/day the team will be way ahead of the game.

4. Overly sophisticated and restrictive workflows

Just because you can doesn’t mean you should. It is very tempting to try to map every detail of your process and force issues through every status. However, won’t take long for team to feel such a rigid workflow getting in their way and they will just stop using it. Keep your workflows as simple and flexible as possible. Prove to yourself you need something more advanced before you implement it.

5. Workflows with no waiting statuses

Ideally every status in a workflow should have a doing and done state. This makes it easy to see if something is actively being worked on or waiting to be worked on. Jira doesn’t support this formally, but you can achieve the same thing by having status pairs like Ready for Development and In Development. This will also allow you to measure your flow efficiency since you can capture the total working time vs waiting time.

6. No distinction between the backlog and planned work

When issues remain in the backlog until work actually begins on them it makes it more difficult to see what work has actually been planned. You achieve that visibility to an extent with versions, epics, and sprints, but it can still be confusing. I always encourage teams and organizations to have a status in their workflows like In Planning. It is a very simple way to distinguish issues that have merely been captured, which is all a backlog item is, vs. issues we have made a conscious decision to implement. In addition it assists in expectation management with stakeholders and allows you to have a much more meaningful lead time measurement.

7. Implementing Unnecessary approvals

I have seen this quite a bit. Because Jira makes it easy to collect approvals in the workflow companies often go crazy and start adding approvals all over the place. Remember, approvals are a constraint and constraints are something we want to reduce and eliminate if possible. Only implement approvals where they are absolutely required such as in regulatory environments.

8. Using Jira as the primary conduit for communication

Another pattern I have found to be very common. Teams begin using Jira as a primary mode of communication with one another thinking they can eliminate meetings/ceremonies. Just don’t!!! Use Jira to prompt discussion and capture the outcomes and decisions made in those discussions, but don’t be fooled into thinking it is a replacement for face to face or online discussion.

9. Burying required information in comments

Comments are a great feature, but they susceptible to the same pitfalls as we have all seen with email and chat tools. People have discussions and make decisions in a chat thread, but don’t bother to put that information into the issue’s description or wherever the story details and acceptance criteria are stored. You should not need to scan an issue’s comment history in order to understand what needs to be done.

10. Notification barrage

The constant bombardment of email notifications from Jira seems to be a universal pet peeve with just about every Jira user I have met. The default Jira notification scheme notifies the Reporter, Watchers, and current Assignees of just about any kind of update to an issue in real-time. It quickly becomes noise and defeats the purpose of notifications in the first place. Cut down on the events that send notifications to just those that are of real value and only to those who really need them. This is one area where customization on project by project basis is worth the time.

11. Categorizing with versions, epics, and/or sprints

I see this all the time. Team use versions, epics, and/or sprints to categorize work. For example let’s say a team has the following three epics:

• DevOps
• Support
• Tech Debt

The above are examples of categories of work rather than something that will deliver specific value. An epic is supposed to represent a deliverable piece of value with a distinct set of acceptance criteria that define when it is complete. Additionally the examples above will go on indefinitely as issues will be continually added to each of them. Teams will do the same things with versions and even sprints. Here is the problem with that approach. It convolutes your reporting and measurement and makes it very difficult for anyone not intimately familiar with your project be able to look at the information and understand what your working on and the progress you are making. Leave epics, versions, and sprints for what they were intended for and use components, labels, and linking to categorize your work.

12. Tracking time unnecessarily

Another case of just because you can does not mean you should. Jira allows you to estimate and capture actual time spent all the way down to the subtask level. For some teams this may provide value, but more often than not it just becomes a lot of overhead and is not terribly accurate on either end of the equation. It might even be a good idea to turn off the time tracking just to prevent temptation.

13. Trying to create the ultimate configuration on Day 1

This ends up being a lot of wasted time especially if you are new to Jira. The configuration options in Jira are extensive and very difficult to anticipate completely ahead of time. Start off with the bare essentials and determine how you need to evolve your configurations based on real world experience and feedback. Jira is easy to change so there is no need to figure it all out up front.

14. Assuming Jira will solve process, structure, or cultural issues

Jira is a great tool, but it won’t make up for flawed processes, structures, or cultures. A very common pattern is for companies to purchase Jira, get their employees training on how to use it and then think they are off to the races with Agile. That is a sure fire recipe for a failed Agile implementation. At best Jira may help expose some of those underlying issues, but it won’t correct them.

15. Using Jira as Big Brother

If you want your teams to completely game the data, grow to hate Jira, and make any information coming from it mostly useless then by all means go that route. Otherwise, don’t even think about using it in that kind of dysfunctional manner. The more teams see Jira as a tool to help them the more it will they will leverage it to improve. The more they see it as a tool to police and judge them the more they will fight it.

16. Blanket rollout of plug-ins

Jira has thousands of plug-ins and they always sound like the greatest thing since cable TV, but unfortunately it doesn’t always work out that way. Try the plug-in out in a staging environment first and then with selected teams in production to evaluate its actual utility and the potential negative impact it may have. Plug-ins can sometimes conflict with one another and they can also have a noticeable effect on the user experience.

16. Backlog hoarders

It never ceases to amaze me how pervasive the idea is that you should never delete anything from your backlog because you might need it one day. There is also the notion that it sends a negative message to the stakeholders who made the request. First, backlogs quickly become an unwieldy mess which really defeats the whole purpose of having an ordered backlog. I did a study once with a company I was working with where I examined the backlogs of 25 of their teams. What we found was that for pretty much every team a story had just a mid single digit probability of being implemented after only 3 months. In other words any story 3 months old or more had next to no chance of being done. Second, closing issues that have very little chance of being done helps manage stakeholder expectations. Better to tell someone their request won’t be done than having them hold out hope indefinitely. Keep those backlogs clean and concise by closing old stories. If you end up needing something you closed it is still available in Jira, but it won’t be clogging up your backlog in the meantime.

17. One size fits all approach

I mentioned you can go crazy with customization, but the opposite problem can be just as bad. Different teams and groups have different needs. Don’t assume what works well for one group will work well for another. You may gain efficiency in terms of maintaining and managing Jira, but in doing so may gum up the works for your teams. It’s always going to be a balancing act between the two. Jira teams and admins need to work closely together to determine what works best on the whole.

18. Having Jira driven by people who don’t use it

I have felt this pain first hand and I don’t wish it on anyone. The people who are leading the Jira implementation and management should be dog-fooding it every step of the way. No excuse not to.

So, there you have it. This is by no means an exhaustive list and like anything else your mileage may vary. I would suggest using the list as things to be aware of and think through rather than a list of absolutes. I would love to hear of other anti-patterns you have come across in your Jira experience and how you have learned from them. As always feedback is always welcome and encouraged.

How can we increase the velocity for our Scrum team?  First, and most importantly is to make sure we understand the problem.  Although ostensibly the problem is low velocity, we should first review the way velocity is being measured, and then compare that to other throughput measurements for this team and other teams.   If Story Points are being used, compare the number of Story Points delivered (velocity) versus the number of items delivered (throughput), and compare both numbers to those of other teams.  Also, are Story Point estimates updated at any time after initial estimates are recorded?  We have observed situations (especially for a new team) where an item was estimated very high but was delivered much faster and easier than expected.  This “mis-estimation” would skew the velocity upwards.   Of course, the same thing happens in reverse even more frequently, due to “optimism bias” (see Thinking, Fast and Slow by Daniel Kahneman).  Due to these factors, it is entirely possible that what we have is a mismatch of expectations rather than an actual case of low velocity.  Expectation management is a critical piece that many IT workers miss.  Even accomplishing the remarkable feat of landing on the Moon may be viewed as an abject failure if management expected a Mars landing.

Assuming we have done our due diligence and are convinced that there truly is a need to improve velocity, there are several options available to increase the velocity of a Scrum team, including process improvements, tooling improvements, scoping changes, and staffing adjustments.  In order to determine the most appropriate thing(s) to change, we should first consider our circumstances and ensure we are addressing the underlying reasons behind the current level of throughput.   Even if we are extremely confident in our analysis and recommendations, we should still proceed scientifically, ensuring we have accurate baseline measurements and performing “safe to fail” experiments that are quantitatively measured to prove their effectiveness.  We should also be aware that some changes take time, so the results may not be immediately visible.

Since we are talking about a Scrum team, an optimum size all else being equal is generally agreed as being between 3 and 9 team members (depending on many factors outside the scope of this article). We should consider:

• Team Size: If the team only has three team members, for example, it’s more likely that adding another team member is a good idea than if the team already has 8 or 9 members.
• Bottlenecks: Are there bottlenecks that indicate where the work gets stuck? Perhaps backlog items are not well-analyzed, so developers need to make many assumptions that turn out to be wrong and lead to rework.  Are there a lot of items stacking up waiting for manual testers to become available?  If there are regularly occurring bottlenecks that are outside the control of the team, then systems thinking tells us that adding additional team members could actually make matters worse.  On the other hand, if the bottlenecks are occurring due to the team lacking some specific skill or authority, then bringing someone with that skill or authority into the team may make a huge difference (e.g. DBA, Operations, compliance expert, tech writer, etc.)
• Release Cycle: Even under the best possible conditions, adding team members decreases team productivity in the short term and the level of disruption may be greater still in the case of replacements.  Therefore, if we are trying to hit a target that is less than a few months away, adding team members may well only serve to delay the team further.  Fred Brooks made this observation in his seminal 1975 classic “The Mythical Man-Month.”
• Team History: Has this team been working together for a long time, and likely suffer loss of morale if a team member was replaced?  Are they all recently hired consultants who have never worked together before?
• Application Criticality: More critical leads to a tighter Definition of Done; items likely take longer to complete.
• Definition of Done: Is the Definition of Done more rigorous than that of other teams? We need to make sure we are comparing apples to apples.   For example, perhaps this team is updating end-user training, design documentation, and compliance items that simply don’t apply to the other “higher velocity” teams.  Taking those into account, it is possible this team is actually higher performing than the others.
• Software type: Enterprise COTS (e.g. SAP, Salesforce) or Legacy software teams often have a lower velocity than greenfield teams. Any large and complex pre-built system has constraints, standards, and guidelines that must be learned, making the task of adding complex new functionality tricky.
• Team Morale: Are people generally enthusiastic about their work or has everyone determined the deadline is hopeless and they have emotionally “checked out?”
• Teamwork Style: Do team members regularly review each other’s work and collaborate as appropriate? Or does everyone hunker down in their cubical and speak only during the daily standup?
• Scrum Process: Is the Scrum meeting held daily? Are sprint planning and review being done, and are retrospectives being held regularly?  There is a big difference between a mature Scrum team that is starting to experiment with some Lean or Scrumban / Kanban processes versus a team that “can’t be bothered” to follow the basic practices (see Shu-Ha-Ri)
• Quality Issues: Is the team experiencing a lot of quality issues? Perhaps more items are not getting completed because they need rework.
• DevOps Tooling: Does the team have CI/CD in place? Are automated tests relatively easy to build or very difficult?

Assuming none of the above issues sticks out as a root cause of slower performance, there is ample time left in the cycle, and the team is amenable and not already full, adding a senior team member or two could indeed be helpful.  In our experience it is best if the team participates in the interviewing process.   We do not recommend replacing a team member except in the case where a team member is widely recognized as a problem by the other team members.   On a Scrum team, incompetence or apathy is immediately noticed by all team members and should be addressed quickly.  Assuming proper HR procedures are followed, replacing such a team member with a more senior and committed person is usually welcomed by the team.

In summary, when looking into how to increase velocity for a Scrum team, we should keep in mind that there are many different possible root causes for “low velocity” on a Scrum team, and adding or replacing team members is disruptive and may even be counter productive.   We should first consult with the team: perform our due diligence and root cause analysis.  We may need to make some small experiments to validate our hypotheses.  Finally assuming the team is amenable, we may add or even replace team members if it makes sense.

Where does systems thinking fit in designing a Kanban system?
STATIK; the system thinking approach to implementing Kanban. We always want to think of the system as a whole and avoid local optimization. The steps in this process are not necessary sequential, but iterative, using learning from one step to inform and influence the others. The steps are:

• Step 0: Identify Services
  For each service:

• Step 1: Understand what makes the service fit for purpose for the customer

• Step 2: Understand sources of dissatisfaction with the current system

• Step 3: Analyze demand
• Step 4: Analyze capability
• Step 5: Modal workflow
• Step 6: Discover classes of service
• Step 7: Design the Kanban system
• Step 8: Socialize the design and negotiate implementation

Why is lead time not measured from concept to cash?
The Kanban system starts when a work item is committed to, and stops at the first unbounded queue. We should also differentiate “customer lead time” versus “system lead time” to be more clear. For example, a Starbucks with a given number of workers can produce coffee at a certain rate, regardless of how many people are in line. The last one in line will have a longer wait. If we want to handle a long line of customers, we should look at the system and see where the constraint is–do we need more cashiers or more baristas? If long lines persist, perhaps it is time to expand the store, or even open up a new one! Maybe that is why we often see multiple Starbucks within 3 blocks of each other in NYC…

When setting a WIP limit you should always take into account the size of your team — true or false?
FALSE. For example, single piece flow sets WIP to one regardless of size of the team. It is more about balancing the constraints and capacities of the system and avoiding bottlenecks. However, setting a WIP limit of the size of the team (or a little more) may be a decent place to start.

What are the disadvantages of using value stream mapping in knowledge work?
Value stream mapping captures a workflow and focuses on timing each step in order to optimize it. In knowledge work, accelerating one step may cause issues downstream due to quality. Also, Kanban boards track knowledge discovery rather than handoffs. The column headings in a Kanban board reflect the dominant activity, not the only activity (e.g. this is why we can have bug fixing in a “testing” column). Value stream mapping was created for manufacturing. On the other hand, value-stream mapping can work well for automated DevOps pipelines, since humans are not involved.

What’s the difference between work item type and class of service?
Work item types capture different kinds of work, such as Epics, Defects, User stories, and the like. At a Starbucks, work items might include Latte, espresso, breakfast sandwiches, and mints. Classes of service are how items are handled. For example, one user story may be expedited, while another may have a fixed due date. At Starbucks, they might receive a request at 11 for a latte to be picked up at noon– that would have a fixed date class of service, and the team would probably not start working on it until about 11:55am. By contrast, if the mayor walked in and made an order, that would probably get expedited!