-
Notifications
You must be signed in to change notification settings - Fork 4
7. FAQs
For each Work Item table in the dataset, the amount of data is as follows:
Last 6 months of data (from the date of refresh)
- WorkItems Blockers
Last 12 months of data (from the date of refresh)
- WorkItems Completed
- WorkItems CycleTime1
- WorkItems CycleTime2
No date limit
- WorkItems In Progress
- WorkItems In Progress2
Sub-tasks are deliberately excluded as (IMO) they do not encourage teamwork and collaboration. More importantly however they typically are not the unit of 'value' in a teams backlog, which is typically at story level or higher.
Lead time measures the total time elapsed from the creation of work items to their completion. Cycle time measures the time it takes for your team to complete work items once they begin actively working on them.
Lead time is calculated from work item creation to entering a 'Done' state category. Cycle time is calculated from a work item first entering an 'In Progress' state category to entering a 'Done' state category.
Velocity (sum of effort/story points) is a metric that is easily abused/gamed and, through my years as a practitioner, I’ve found it to be pretty useless as a metric. It forces teams to focus too much on ‘getting our points up’ or just artificially inflating estimates and thus ‘increase velocity’. Countless studies (including my own) have proven that there is little/no correlation in points estimation, and that it is no better than using count of items (otherwise known as Throughput). Plus, Senior Managers and Executives don’t want to hear about story points, they want a language that makes sense, not some obscure voodoo :) This dashboard is all centred on flow and transparency, in a language that is simpler to digest, hence why velocity is excluded.
The Blockers page only works if work items are 'labelled' as Blocked. Any other custom ways of identifying blocked work will not work. Please contact me if you have ideas about how else to go this or to share how you block items currently.
Changing the forecasting visuals is relatively simple to do. Reasons for this could be if you don’t have ‘enough’ data yet but have a reasonable amount, or if you need to "throw away" old data. Just change the 'Input data range' number for the number of weeks worth of data you do want to use. Watch the % stability though!
This isn’t actually true, and a common myth:
-
With 5 samples we are confident that the median will fall inside the range of those 5 samples, so that already gives us an idea about our timing and we can make some simple projections (Source: Actionable Agile Metrics For Predictability)
-
With 11 samples we are confident that we know the whole range, as there is a 90% probability that every other sample will fall in that range (see the German Tank Problem). Knowing the range of possible values drastically reduces uncertainty.