
How’s that sprint going? ZenHub reporting and GitHub data will tell you - rohamg
https://www.zenhub.com/blog/zenhub-reporting-suite-github-insights
======
wdewind
My experience has been that no one needs a burndown chart to know how a
project is going, and, to the extent that you do, it usually points to some
mismanagement and an attempt to fix it through intensifying project management
rigor. Especially with early stage startups, where the requirements are
changing rapidly and throughout the project, I think this stuff represents
very real overhead that's just not really that useful. In larger companies,
where stuff like this is typically used as reporting up a chain, it can be
slightly more useful to get a holistic view of the organization, but again,
I'm just not sure it's worth the effort, and I really question resting a
significant amount of decision making power on this over qualitative data.

To be clear: I'm not throwing all project management methodology to the wind,
but this promises to give you a fancy chart that will "identify bottlenecks in
your development process" and I'm sorry if you need a graph to know where
those are I think there are probably larger problems in your organization.
Identifying bottlenecks is easy, fixing them usually involves much higher
level management functions like recruiting and training.

~~~
himynameisdom
As an Agile coach, I agree to an extent. Metrics can be and are often times
weaponized by management to exact control over a project.

I wish more organizations saw Agile metrics, or any metrics for that matter,
as conversation starters for the team to discuss how things are going and
how/when to adjust course. It's a challenge to change habits of making binary
decisions based entirely on metrics.

~~~
screaminghawk
I have to agree as well.

Our team has switched from a burndown chart to a "Confidence Check" at each
standup. On the count of 3, we each hold up fingers rating the chance to
complete the sprint out of 5. It's been a good way to see if the blockers are
likely to be overcome and see if anything was missed etc. Our combined gut
feel is a lot better than the burndown chart for reporting and for starting
conversations.

~~~
wdewind
That feels like a _way_ more reasonable effort to signal-value ratio to me.
Thanks for sharing.

------
valuearb
I feel like the use of metrics is often just a crutch to avoid real
management/leadership decisions. Sprints are meaningless overhead unless they
are coupled to important deliveries. Often they aren't.

In my real world experience software doesn't get delivered within sprints, it
gets delivered when it's ready. And decisions about what to deliver aren't
made by the sprint team.

Anyone can pad story points enough to look like a sprint super-hero. The key
focus should be what are you building, are you building it the right way, and
what can we do to deliver it faster/better. Sometimes the right answer is stop
holding meetings, and just get out of the way and let the team focus on the
problem without interruption for a while.

