<div dir="ltr">RE anecdotal evidence: in my experience, if you start asking people to bring evidence to support their complaint, they will do so more often later and over time. People appreciate it when you want to find a success metric for their issue. <div><br></div><div>RE low respondents:</div><div>Try keeping the survey as light as possible. </div><div><br></div><div>You can also game-ify it. Plant an easter egg in it. The first person to finish the survey and say a secret phrase to you gets something.</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 11, 2015 at 4:38 PM, Joel Aufrecht <span dir="ltr"><<a href="mailto:jaufrecht@wikimedia.org" target="_blank">jaufrecht@wikimedia.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><b>tl;dr:</b> Metrics targeted exactly to the specific things we want to change may be more helpful than general opinion surveys.<br><br>David was extremely helpful in clarifying my thinking on how I should measure the effectiveness of the VE process work I've been doing.  So I want to brain-dump before it evaporates.  Context: Neil and I did a general process survey of the VE team and their stakeholders in April/May, identified a handful of challenges, and proposed five specific interventions, all of which are currently underway.  The most people-intensive intervention is negotiating Service Level Understandings between the VE team and each stakeholder group, and using these discussions to uncover contradictions in goals and/or resource levels.  Arthur suggested I use surveys to measure if these SLU discussions have any effect.<br><br>David proposes getting much more specific.  For each SLU discussion, identify several specific actions to be taken, that are measurable, and measure them.  Try to capture both input and output/outcome.  For example, if QA complained (I'm inventing this as a fake example) VE keeps releasing patches with IE bugs, then the VE team might say in response, well, you don't test our patches in time and we have to release untested code.  So they might agree on a lead time and a level of QA availability for testing.  Then, we could measure an input (time it takes for each patch to be tested) and an outcome (# of critical IE bugs found after release).<br><br></div><div>Because we don't know what to focus on until after the SLU meeting, we probably don't have any Before metrics.  Where possible we can reconstruct Before metrics, but we would probably have to accept having mostly qualitative/anecdotal Before.<br><br></div><div>I will also proceed with a survey for all stakeholders included in the process review (~30 people), but this doesn't have to be specific to the SLU intervention.  Instead, I can survey for all of the ~10 challenges identified:<br></div><div>1) Do you agree that X is a problem?<br></div><div>2) How does this affect you?<br><br></div><div>And run the survey once now, as a retroactive baseline ("As of april/may, did you think ...") and then in a few more months, when most of the recommendations are implemented and mature.<br></div><div><br></div><div>However, it occurs to me that I did run a similar survey in May/June, and got 13 responses.  So maybe I won't do a retro baseline, but instead just run a future survey later this year.<br><br></div><div></div><div><div><div><div><div dir="ltr"><div><div dir="ltr"><font color="#888888"><div><b>--<br>Joel Aufrecht<br></b></div><div>Team Practices Group<b><br></b></div><div>Wikimedia Foundation<br></div></font></div></div></div></div></div>
</div></div></div>
<br>_______________________________________________<br>
teampractices mailing list<br>
<a href="mailto:teampractices@lists.wikimedia.org">teampractices@lists.wikimedia.org</a><br>
<a href="https://lists.wikimedia.org/mailman/listinfo/teampractices" rel="noreferrer" target="_blank">https://lists.wikimedia.org/mailman/listinfo/teampractices</a><br>
<br></blockquote></div><br></div>