Content Comparison

...

1. A value stream or sequence of activities necessary to deliver a product or service to a customer (an internal or external ) customer - Gartner.

2. All of the work items that are currently in flow within the value stream or that have passed through the stream for the period of time we wish to review. Put another way, all of the demands that have been placed on the delivery system.

3. All of the people involved in performing the work that must occur within the value stream. These people represent the capacity of the delivery system.

You may have one or many delivery systems in your organisation. A delivery system may have one or many teams participating in it. You must determine the bounds of your measurements. You could start to measure work when a request is received from a customer, or perhaps you reduce the scope of your measurements and start once development begins. Regardless of your decisions, there are some factors you should consider.

Include all of the work in the system

Deciding whether to initiate measurements at the first or fifth step of your value stream hinges on the objectives of your measurements and your team's comfort level with flow concepts. Ultimately, the decision rests with you. The same principle applies when determining whether to analyze a month's worth of data or six months' worth. The choice is yours.

However, there is one crucial requirement that must be met to maximise your results and insights: for the period under review, ensure that you capture all the work that has entered the value stream, rather than just a subset of the work for the period under review. To illustrate the importance of this, consider the following real-world example.

This engineering group consists of three teams, each comprising seven engineers. All teams are dedicated to developing features for a single product. In addition to feature development, they also regularly address bug fixes, security concerns, and technical debt, which are often prioritized for resolution. To effectively manage track this workload, the group has established specific issue types in Jira to document their efforts. The image below illustrates a detailed breakdown of the group's activities over a span of seven weeks.

...

Neglecting to capture the full complete scope of work performed by the team hinders obscures our understanding of a pivotal critical factor that influences affects the performance of a delivery system: the relationship between demand and capacity. In this scenario, demand or Given that the work items mentioned have an average cycle time of 11 days, a demand of 3 items per engineer per week , surpasses exceeds the available capacity. Any system facing demand that surpasses its capacity , which will lead to will inevitably encounter delays, waste, bottlenecks, and an inefficient delivery systeminefficient delivery. While focusing solely on feature development in this scenario reveals issues in the data, it is impossible to pinpoint the root causes of these problems without a comprehensive view of the bigger picture.

Don’t double count

By default, Jira includes issue types that serve as parent issues for other issue types. For instance, an Epic typically represents a substantial body of work that is divided into Stories or Tasks. An Epic will have both a start date and an end date; however, it does not directly represent work itself. Instead, it acts as a placeholder for its child issues, which provide a more accurate depiction of the actual work involved.

...

Here is an example autogenerated JQL query with the suggested issue type amendment:

...