Why are we only concerned with processes associated with the Scrum Sprint? This is one of many workflows for provisioning work. Simply following Scrum protocols isn’t sufficient to embrace an Agile mindset. Your team needs to build a seamless, and simplified provisioning process. Ruthlessly eliminate redundancies and dependencies. Identify hurdles and extract built-in lag times within and between various workflows, that drag down the overall process. Let’s take a holistic view of work pathways, in the light of improving their effectiveness.
Author: Mark Haynes, https://dmarkhaynesconsulting.godaddysites.com/
“Prototypes are Easy, Production is Hard.” – Elon Musk
We will shape the conversation with the following:
- Definitions of work and workflows,
- Pain points, to assess if you’re going off the rails,
- Examples of Scrum workflows,
- Evaluation questions, and
- Policy checkpoints to help guide your team.
Definitions
Work
Work is an action that transitions a product or service from one state to another. Work performed has an input, a transformation, and an output. In an Agile environment, work valued by the stakeholders provides a qualitative or quantitative improvement. Manageable Work are tasks parsed into a size that can be accomplished reasonably well, within a limited time.
Workflow
A workflow is a sequence of tasks describing a pathway of activities that transforms a product or service from its initialization to completion. Waterfall workflows are well-defined, described sequentially going from one phase to another. Agile favors less formal, cyclical, and even concurrent workflows. Scrum often uses workflows, processes, and Ceremonies interchangeably. Workflows may be chaotic, emerging as one completed task identifies new pathways.
In Lewis Carrol’s, Through the Looking-Glass, the Red Queen states, “Now, here, you see, it takes all the running you can do, to keep in the same place. If you want to get somewhere else, you must run at least twice as fast as that!”
How fast is your team running?
Pain Points
- The Product Owner is an order taker and the team fulfills them.
- The Backlog has no apparent organization or archiving strategy.
- User Stories languish as they wait for hand-offs.
- Retrospective Action items drag on from Sprint to Sprint.
- Promotion to production is inconsistent, with overlapping changes.
- Resolving defects in production can crash the Sprint.
Workflows – A brief overview
The quintessential question is “What’s the duration between the conception of a new feature and its implementation?” Any delay in Time to Market, due to inefficient processes, unproductive activities, or delays within or between workflows is a waste. Consider a typical set of workflows and ask yourself what opportunities exist for streamlining the current operations.
Managed Product Development involves developing, launching, and improving products or services.
- Managed Product Backlogcontains features, infrastructure changes, defects, or any activities the team needs to achieve a specific outcome.
- Managed Requirements area subset of Managed Product Backlog, specific to defining requirements.
- Managed Sprint Backlogtraces requirements implementation from “Ready” to “Done” states.
- A Managed Retrospective “Action Board” follows process improvement work items, typically identified at Retrospectives.
- Managed Software Deployment is the workflow for promoting software to various software environments.
- Managed Quality Assurance and Defect Resolution are flows associated with testing or defect resolution.
- Enterprise Agile,IT Governance, Verification & Validation, and Legacy groups like Release Management and Change Control Board will be out of scope.
Managed Product Development from a Scrum perspective involves workflows for creating a product vision and producing a Product Roadmap or Value Stream Mapping. This article will focus on the Product Roadmap.
Managed Product Roadmap
A product roadmap is a high-level visual summary that maps the vision and direction of your product offering over time. It helps the team understand their commitments to the deliverable goals of a Sprint. Resulting artifacts may result in a “Now-Next-Later” document.
Product roadmap goals:
- Describes the vision and strategy,
- Provides a guiding document for executing strategy,
- Obtains stakeholder alignment,
- Facilitates discussion of options and scenario planning, and
- Communicates with customers.
The Roadmap needs to be open to inquiry by the Agile team to understand the organization’s vision, milestones, timelines, and priorities.
Now let’s dig into a few evaluation questions:
- Does the team understand the product vision?
- Is the Roadmap a glorified Product Backlog, at a User Story level?
- Is the Roadmap regularly updated to reflect changes in priorities, resources, budgets, and external pressures?
- Are adequate resources available to accomplish the Product Vision?
- Were Stakeholders involved in writing the Product Roadmap?
- What’s the cycle time of a new product offering?
Managed Product Backlogs
The Product backlog is a list of requirements, derived from the roadmap for the development team to complete during the Sprint. As described in the Scrum Guide, it’s an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.
A good product backlog has four characteristics (DEEP):
- Detailed appropriately
- Estimated
- Emergent
- Prioritized
This is your team’s messy closet. It requires organization, enhancements, and an archival strategy.
Here are a few evaluation questions:
- What problem will be solved or value added by the new feature?
- Is this feature doable within the proposed timeframe?
- How is the Product Backlog stocked with future work?
- How is it organized, by Epics, Themes, or functionality?
- Are historic, or obsolete features periodically reviewed?
- What’s the archival strategy?
- How long does it take for a new feature to be included in the Product Backlog?
Managed Requirements
Requirements are a statement of work, for functional and non-functional features. They are the source of truth and authorization for any changes to the product or service. Non-functional includes enhancements to security, performance, infrastructure, or implementing vendor tools. In short, any work performed requires a written requirement. User Stories targeted for the next Sprint are brought into a Ready state and promoted to the Sprint Backlog. Consider the following transitional states of a Requirement:
- Elicitation is the gathering and discovery of requirements from stakeholders and other sources.
- Elaboration isanalysis to reach a richer and more precise understanding of each requirement.
- Validation confirms the correctness, completeness, testability, and lack of requirement ambiguity to build a solution that satisfies the business objectives.
- Acceptance is an acknowledgment by the Stakeholders that they are ready to be allocated to releases and iterations.
- Maintenance is upkeep activities performed on the Product Backlog’s Themes, Epics, and User Stories.
A few evaluation questions to consider:
- Is your Product Owner, familiar with the elements of a good User Story?
- Do User Stories go through Validation where Stakeholders and the Scrum team can verify the Requirements?
- Are all requirements written in a standard, well-understood format, such as User Stories?
- Is a Kanban board used for Requirements Management?
- Are there multiple Product Owners representing competing Stakeholder requests?
- How long does it take from its conception before a User Story is included in a Sprint?
Managed Sprint Backlog
Agile Alliance defines a sprint backlog as the subset of product backlog that a team targets to deliver during a sprint to accomplish the sprint goal and make progress toward the desired outcome. As described in the Scrum Guide, the Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), and an actionable plan for delivering the Increment (how).
This is the crucial workflow for a smoothly operating Scrum or Lean team. A Kanban board provides visual clues of workflow turbulence. It’s an essential tool for resolving impediments, and taming the monster User Story. It’s more than a glorified to-do list and represents a significant improvement over inflexible, cumbersome Gantt Charts and Work Breakdown Structures.
Consider the following talking points:
- Are Ceremonies and events well defined, with clear expectations?
- Does the Kanban board contain a “Hold Until…” column, where User Stories languish in a black hole?
- Have Work-in-Progress limits been determined?
- Is Sprint Planning a catch-all event for User Story enhancement, estimating, and prioritization?
- Do User Stories require activities outside their Sprint, such as a Pre-Ready or Post-Done state?
- Are sufficient User Stories available for Sprint planning, to meet capacity planning activities, or for the next trigger pull?
A Managed Retrospective “Action” Board
During the Retrospective the team solicits process improvement items, based on lessons learned during the last Sprint. A typical format used is: what worked, what didn’t work, and what improvements can be made. By no means mandated, the Action Board becomes a to-do list. Which in turn becomes an extension of the Sprint backlog. Items should be tracked like any other User Story. If done separately they become simplified User Stories, at task level. Not tracking Action items risk having them ignored and losing the Retrospective as the change mechanism in Scrum.
What’s your team’s Action Board process?
- Identify and assign – Elicitation.
- Investigate – Elaboration.
- Update Action Board/create User Story.
- Review – Validation.
- Conduct Sprint Planning.
Consider the following evaluation questions:
- Are Action items written as User Stories?
- Are all Action items doable within a Sprint?
- Are Action items assigned to individuals?
- Are Action items within the team’s purview to complete?
- Do Action items fall off the radar or are rarely finished?
Managed Software Deployment
Software deployment requires specialized environments with specific configurations, procedures, and tools for managing libraries and promoting components. Processes, even highly automated ones may have unique workflows.
Your environment configuration may be different, but consider the workflows for the following types of environments:
- The local environment is where developers write software, generally available to anyone with access to application development.
- The development environment is where developers upload code and merge with multiple branches in a robust environment.
- Testing environments are designed to simulate a production-like setting.
- The Staging Environment is the final resting place for software before it’s moved to production.
- The production environmentis highly stable with strong infrastructure support able to handle the demands from various contingencies. Its primary purpose is to serve the end user.
- The customer demo/training environment is used to demonstrate application functionality to Users or provide training sessions.
A few evaluation questions to consider:
- Are development libraries separate from testing libraries, from production libraries?
- Are tools available to manage, track, and move components from one library to the next?
- Is the entire team familiar with how to deploy to production?
- Is your process automated or manual?
Managed Testing and Defect Resolution
Are workflows associated with Quality Assurance testing and defect resolution? The Acceptance Criteria establish the criteria the Product Owner needs to accept or reject the User Story. They’re a minimal set of high-level testable statements.
One standard format is:
- Given {some context}
- When (some action is carried out)
- Then {a result indicating success or failure)
Your testing process may be more robust or driven by regulatory requirements. Here are a few evaluation questions:
- Does the team need to undergo periodic “Bug Hunt” sprints?
- Is root cause analysis on production defects performed?
- Are test tools available for test management, automated testing, and defect tracking?
- Does the Quality Assurance Analyst rush through system testing to test all the User Stories?
- Is there sufficient time to conduct Integration, UAT, or End-to-end testing?
Policy Checkpoints
Consider establishing a few policy statements as part of your working agreement. Nothing elaborate, something your team can reference, as needed. It’s important to discuss and achieve a consensus, maybe at your next Retrospective. A few examples:
- The Product Backlog will be maintained, & obsolete items will be archived.
- All work items are captured as User Stories and tracked on the Kanban board.
- Only User Stories in Ready condition will be considered for Sprint Planning.
- Retrospective Action Items will be treated like User Stories.
Closing Thoughts
It’s easy to waste time on tasks masquerading as work that provides minimal value. The Agile Manifesto cautions us against the seductive nature of creating excessive documentation, attending endless meetings, or building oppressive processes that add little to the final product.
Look for ways to eliminate productivity traps, such as redundant processes, low-priority tasks not valued by the Stakeholders, make-work assignments, and hand-off issues between processes.
References
Staff writer. ( 2021, May 3). Gadgets 360 An Notv Venture. Elon Musk on Making Electric Cars:’Prototypes are Easy, Production is Hard’. https://www.gadgets360.com/transportation/news/seo-elon-musk-tesla-electric-cars-ev-roadster-model-3-s-y-twitter-india-market-2427217
Fridman, Alexander. (2023, April 11). Release. A Simple Guide to Software Environments. https://release.com/blog/a-simple-guide-to-software-environments
Mackie, Caitlin. (2021, March 14). Easy Agile. DEEP: The 4 Characteristics of a Good Product Backlog. https://www.easyagile.com/blog/product-backlog/
Staff writer. (2022, October 25). Craft.io Team. 7 Product Roadmapping Mistakes and How to Avoid Them. https://craft.io/blog/7-product-roadmapping-mistakes-and-how-to-avoid-them/
Popovych, Anna. (2022, August 17). Clockwise Software. 8 Product Roadmapping Mistakes and How to Avoid Them. https://clockwise.software/blog/product-roadmapping-mistakes/
Priyanka. (2024, October 7). Productlogz. What Can Cause an Unstable Product Roadmap: Reasons + Examples. https://www.productlogz.com/blog/what-can-cause-an-unstable-product-roadmap
Staff writer. ProductPlan. The Ultimate Guide to Product Roadmaps. https://www.productplan.com/learn/what-is-a-product-roadmap/
Christian, Andrew. (2024, May 16). Requirements. The Key Characteristics of Good Software Requirements. https://www.requiment.com/key-characteristics-of-good-software-requirements/
Varadharajan, Nivedha. (2020, April 29). Devopscube. Release Management Explained: Dev to Prod Deployment Process. https://devopscube.com/release-management-explained/
Staff writer. (2018, June). Informa. Simplify the production deployment process with these tips. https://www.techtarget.com/searchitoperations/essentialguide/Simplify-the-production-deployment-process-with-these-tips
Staff writer. Agilebin. The Ultimate Guide to Setting Up and Using Retrospective Boards. https://www.agilebin.com/blog/retrospectives/the-ultimate-guide-to-setting-up-and-using-retrospective-boards
Murphy, Anthony. (2022, July 13) LogRocket. The difference between product, sprint, and release backlogs. https://blog.logrocket.com/product-management/product-vs-sprint-vs-release-backlog/
Staff writer. (2024, November 21). Kissflow. What is a Workflow? – Definition, Types, Examples [Updated guide for 2025]. https://kissflow.com/workflow/what-is-a-workflow/
Sweden, Goteborg. (2020, December 12). Art of teamwork. How to Implement Action Items Captured in a Retrospective. https://www.artofteamwork.com/how-to-implement-action-items-captured-in-a-retrospective/
Krasteva, Iva. (2024). businessmap. Agile Workflow: Your Go-To Guide to an Adaptive Process. Agile Workflow: Your Go-To Guide to an Adaptive Process
Leme, Guilherme. (2024, August 14). pipefy. What is Workflow Management? 2024 Guide. https://www.pipefy.com/blog/what-is-workflow-management/
Kao, Clement. (2024, October 22). The Product Manager. Product Roadmaps: The Ultimate Guide for Product Managers. https://theproductmanager.com/topics/product-roadmap/
Gibbons, Sarah. (2020, November 29). NN/g. The 6 Steps to Roadmapping. https://www.nngroup.com/articles/roadmapping-steps/
Athuraliya, Amanda. (2025, February 12). cocreately.7-Step Product Management Process: Stages, Best Practices and Templates. https://creately.com/guides/product-management-process/
Stevens, Emily Y. (2022, July 15). What Is the Product Management Process? The 7 Stages Explained. https://careerfoundry.com/en/blog/product-management/product-management-process/
About the Author
I am a renaissance man trapped in a specialist’s body. I started as a biologist and that’s why I became an IT guy. I love science, but it doesn’t pay the bills. I have been an IT professional for many years. I used to be a software developer with an elegant language for a more civilized age. I became a Quality Assurance guy because it’s better to give than receive. I have been a process improvement specialist because it’s easier to negotiate with a terrorist than a Methodologist. But lately, I’ve been working as a Scrum Master and Agile Coach. I have drunk the Kool-Aid and it tastes good. Agile is a philosophy, not a methodology. In interviews, people often ask how long you’ve been Agile. My answer is always. I just didn’t know what it was called before.