Skip to main content

Team's successes and measurements

Last post 03:07 pm July 14, 2022 by Daniel Wilhite
4 replies
02:52 am July 14, 2022

Hello Community!

I have a question regarding utilizing objective measurements. In your experiences, what are some of the best ways to measure a team's delivery objectively? I have heard of cycle times and lead times. Any other recommendations? We want to showcase that teams are delivering values objectively and also showcase a team's success in the program management level. Any suggestions?


04:47 am July 14, 2022

You could consider Evidence Based Management:

https://www.scrum.org/resources/evidence-based-management

Maybe teams aren't delivering value objectively, and that's what you need to evidence. It doesn't sound as though value is understood here, or that anyone can really account for it right now.

So never mind about trying to "showcase" anything to "program management". There are organizational impediments to agile practice for which servant leadership is required. That's what needs exposing and those senior leaders may need to be put to work.


09:01 am July 14, 2022

Yeah I tend to agree with Ian. 



You're asking about measuring value, but then referencing things designed to measure outputs. 



I'd go as far as to say that measuring output is actually a BAD idea until you can define and understand value in your context. 



There isn't going to be a one size fits all, but customer satisfaction, product use, sales, and all sorts of other indicators can tell you if what you're producing is valuable. 



But the best guide is just to spend as much time listening to as many customers as possible. 



Once you have that, you can measure things like cycle time, velocity etc. 



The most interesting and common result though, that will probably surprise you, is that these two concepts tend to  be inversely related. 



Ie, customer value and satisfaction goes up as we deliver LESS. 



getting to that point of visibility is usually the point that conversations get really interesting. 


01:38 pm July 14, 2022

You know, at the end of every Sprint you have an item to add to the list of thigs delivered: the Sprint Goal.



If that's what you report, the team will be incentivized to focus on the Sprint Goal.



If your management wants numbers, ask them why, and explain software developers are highly schooled creatives. How do you measure a musician's work? Notes played? Songs performed? Are we sure they don't play out of tune if we measure how many notes/songs they played? No, you have them deliver value, and measure the happiness of the public.


03:07 pm July 14, 2022

I'm going to jump on the bandwagon.  I do not believe that there is any kind of a number you can use to measure value delivery.  That is because value to one person is not the same "number" as it is to someone else.  That is why if you go to a store to buy a shovel, it is the same price to everyone.  But a person that uses that shovel once a month will see a completely different value statement than the individual that uses everyday. 

Everything that my counterparts have said is true.  Stop thinking in terms of metrics with numbers associated to them and find ways to show the value that is being derived from the stakeholders.  And remember that a stakeholder does not have to be someone outside your company that uses a product.  Your internal marketing department, your support department, your IT department, local or federal government could all be stakeholders depending on the work that is being done. 


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.