Trying to figure out what this represents? If standard deviation is high, does this represent inconsistent productivity?
Add a comment
|
3 Answers
The short answer: smaller blue area on a control chart means easier forecasting on that project.
- The blue area in the JIRA control chart, is the standard deviation. Standard deviation is a key concept in statistics. JIRA calculates the standard deviation itself, among a few methodologies that can have been used, JIRA decided that an approach derived from tasks is better than methodologies derived from time. To put it simply, it is calculated by using groupings of 20 tasks.
- The lower the standard deviation, the less the team deviates from its "rolling average", and the more predictable team performance on that point of time. This means accurate forecasts while standard deviation/blue area is low/small. While the opposite, high and/or inconsistent standard deviation from its rolling average means that any forecast should be deemed unreliable, a stretched goal at best.
- A large standard deviation to the rolling average - could represent inconsistent productivity but this is not necessarily the case. The methodology that JIRA uses to calculate it (see my first point) could be grouping "pears and apples" that would make productivity analysis void.
Standard deviation is a measure of the spread of the data
As you can see from the Wikipedia article on Standard Deviation:
A low standard deviation indicates that the data points tend to be close to the mean of the set, while a high standard deviation indicates that the data points are spread out over a wider range of values.
In my opinion, higher standard deviation does not necessarily "represent inconsistent productivity". It might just be the nature of the domain. Ken Schwaber noted in his books that complexity in software projects is influenced by requirements, technology and people. If we jump to the conclusion that higher standard deviation (arising from higher complexity) is entirely due to inconsistent productivity (relating to people), we may be overlooking the other two factors.
Also, newly formed teams take time to gel together and arrive at a steady pace of output. See the Wikipedia article on stages of group development.
answered Jan 11, 2018 at 20:20
In general terms, the standard deviation means deviating from any of the standards defined by Industry standards, or by organization standards, or by your Customer standards and/or by your Project standards.
These standards when set quantitatively is easier to measure. The visual presentation that could help everyone understand is by using the Charts. One of the charts that could represent data statistically is known as Control charts . Control charts help to represent the data pretty clearly. However, there are set of rules that need to followed and to be understood prior presenting the data in the Control chart.
Now your question would be what should I Control? If you unable to comprehend or understand the pattern that is causing the failure, control charts will not help. Rather tools like Fish bone, Pareto, etc. will guide you understand the variables that you need to monitor and control.
For the Control charts, the variables that you could monitor for improving (read as continuous improvement) could be defects, fix cycle, scope creep, design issues, or any other data point that is part of your critical success factors identified by your Customer and by your Project team.
Now, let us move on to the next question: Why would you need so many standards and how would you measure it in the Control chart? This where the crux is. The Control chart clearly segments the standards into two groups: 1) Specification, 2) Control.
Specification is the limit set by the Industry, your organization, by your Customer. Consider the specification as the guideline. Control is the limit you set for your Project. This could be because you would have tailored many variables based on your project requirement.
Certain organization(s) begin by baselining the data with the Industry specification. While others will not and will tailor based on their comfort level. There are many such rules here which I will not step into. However, I have been recommending my Clientèle to arrive at the control limit after brainstorming with their team. Later, baselining the limit after couple of deliverables shall enhance the comfort level of the Project team.
The specification has the min and max level set (boundaries) known as Upper Specification Limit (USL) and Lower Specification Limit (LSL).
For the Control limit (boundaries) set by the Project it is known as Upper Control Limit (UCL) and Lower Control Limit (LCL). Now, you see, it does make sense, right?
When the data gets plotted into the Control chart, it would clearly show the yellow-line and the data points to answer whether the data points are in control or are there any outliers.
Hope you are able to catch the information up until now.
There are three different ways to calculate the standard deviation. I will not get into that. Just keep this in mind. Depending on the software other than the statistically enabled ones (Minitab, SPC, etc), most the product would use average of range.
Now, to your question about Jira Control Charts. Jira follows Agile workflow. The details mentioned above are all meant to be for traditional purists like me who would still bend on these items purely to prove the point. However, I am forced to follow the Agile way (that’s where the moolah is…), and the agile purists do not believe in using the Control charts as the manifesto does not recommend to go by Industry standards rather follow the standards of your Client.
So, what does Jira use and how is it used in Jira? Agile follows the Sprint model – the more the releases the better the confidence level (early feedback) of your Client and better profitability for your organization. That’s the mantra.
Now, the key variables in Jira shall be the Cycle time. This variable tracks the time taken to close the ticket from the time it is assigned to. Please do remember that if the ticket is reopened, the cycle time increases. This makes sense in terms of Agile. Because Agile talks about only Value and nothing else. Just look at from the Client’s perspective. The only question they would ask is what’s your time to market? Ah, the cycle time again. You see, the point here?
The next metric used is to produce in the Control chart is Rolling average. The rolling average is based on the average cycle time at every key point; wait time . This also makes sense. Because this will highlight on how long does an issue waits to get resolved. Wow! It is easier to monitor and track the outliers.
The next is your data point – standard deviation. This just paints the picture to show how much the project deviates from the rolling average. Do you understand now?
This means, never worry about standard deviation when using it in Agile as productivity measure, rather understand the cycle time, understand how the rolling average is. Later apply the techniques to control these measures. As simple as that.
However, this measure (standard deviation) can also be used to predict your teams confidence in producing the shippable software - not productivity. Never get into productivity here, it will not answer your question.
Long story short, Standard deviation = Confidence level and not Productivity. How confident is your team to produce shippable software? How much X times will it deviate from normal cycle time? Questions such as these and many such more can have a clear answer. Not productivity. Nope, not productivity. Period.
You got to bear with me for such a long explanation for one-line question. The reason is to help you and others who do not come from Process compliance understand the picture better.
Hope this helps you.
