Discussion: What sort of useful things could we put on the Statistics View?

[.dan.g.]

Hi All

The Statistics View was always meant to display more than a simple burndown but I always seem to prioritise other tasks over it.

Partly that's because I don't have a clear idea of what it could be, hence this post.

If you are interested in metrics about your processes please suggest what metrics you would find most useful.

eg. 

1) Graph the relationship between time estimated and time spent to see if bigger tasks perform worse than smaller ones

2) Graph bugs by category (pie chart)

3) Proper sprint graphs

[Tony G]

Tasks by time period: per week, per month, within date range

- New tasks (per creation date)
- Tasks processed, according to log, not modification time which could have been a mass change of tag or status, to understand how many items are actually being touched over time
- Time estimates for new tasks: to see over time if projects are getting larger or smaller to plan resources
- Actual vs estimate over time for completed projects: reveals performance during crunch periods or with specific resources
- Pie by status, by assignedTo, by tag, by priority (parent tasks only), and yes by category
- Costs over time and by category/tag/version.

Using custom fields could be helpful. For example, Estimated Completion Date and Actual Completion Date would provide the same sort of insight as time estimates versus actual.

I could go on. I think a view like this never has an end as far as options for fields, filters, and chart type. Even as an individual developer I like to see stats on how much time I'm spending on small clients/tasks versus large, how much time I'm wasting for specific clients over time, or how much time I need to spend in email with some clients versus others compared to the total number of hours.

In addition to a view of statistics, I sort of wish ToDoList were adept a logging details to files which could then be processed by any other reporting tools. Having those statistics handy would then open up all kinds of possibilities for reporting. I guess this can already be done with code that parses the backups, and logs specific delta changes. But I'm thinking TDL itself could log delta data which would allow a sort of temporal view of how the data changes over time. So for example, if there were a time-stamped log entry indicating a task is being created or closed then office managers could measure usage of the tool itself by specific users. We could also track how many times estimates get changed and how due dates shift. And we could see tasks moving back and forth between Development and QA or from UAT back to Development. This couldn't replace statistics from live data where we see statistics for when projects actually start and end and where they are now.

In general, I'd suggest that the built-in goals for this should be modest, leaving business-class requirements to plugins - and I'd relish the opportunity to provide such components. I started a thread about addons like this in the LinkedIn group.

Regards,
T

[.dan.g.]

>> I could go on

Please do, but I also need depth as well as breadth.

[Brendan T]

Hi Dan,

perhaps an obvious point, but one to mention anyway.  Whatever statistics views you implement will be a function of the data available and in most cases it will require user entry. So, to have very fancy statistics views it may require more stuff to be entered by the users.  Ideally, this would be minimized so the statistics come with little additional input effort.  Perhaps some ideas from this point of view.

1. Tony already mentioned about plotting by category for example and I guess that can be applied to other inputs, tags, status etc.  There is already a function in TDL to help here - inheritable task attributes.  So, all sub-tasks already get these entered automatically so saves user input.
2. The ability to recognise when a task is "active", may be very useful for statistics.  Personally I would not have the discipline to start and stop an active switch every time so ideally this again would be invisible.  Perhaps a couple of ideas to indicate start of "active", would be when the timer is activated or in my case when the status changes to "in progress", which works well with the kanban view where the status is updated when dragged into the in progress column.  Active status could cease when the mouse is inactive for some time, the status changes to done or timer is stopped.  I think this "active", would have then many ways you could slice and dice that data.  A window may then be useful to indicate the active task that is being tracked.
3. Discerning field information from the title entry.  In this case some keywords would be recognised when entering the title information to populate field data, for example !tomorrow would mean the start date is tomorrow etc.

Brendan   

[.dan.g.]

>> Ideally, this would be minimized so the statistics come with little additional input effort.

That is my plan.

[Koruneko]

Hi !
In addition to the burndown view, would it be possible to have a cumulative flow diagram (ie : http://wall-skills.com/2013/cumulative-flow-diagram/) ? It would be interresting to retrieve the main Kanban/project management indicators ...
don't know if it's easy or not, interesting for others or not ...

Regards,

[SJ]

various charts like : http://wiki.servicenow.com/index.php?title=Scrum_Charts#gsc.tab=0

can be included. Specially velocity chart. 

Also 

a monthly, sprint wise, day wise breakdown statistics would help.