<div dir="ltr">On Mon, Sep 23, 2013 at 12:21 AM, Siebrand Mazeland (WMF) <span dir="ltr"><<a href="mailto:smazeland@wikimedia.org" target="_blank">smazeland@wikimedia.org</a>></span> wrote:<br><div class="gmail_extra">
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Hey Diederik,<br><br>I think a lot of what you describe can be covered by a Definition of Done[1]: "Definition of Done is a simple list of activities (writing code, coding
comments, unit testing, integration testing, release notes, design
documents, etc.) that add verifiable/demonstrable value to the product.
Focusing on value-added steps allows the team to focus on what must be
completed in order to build software while eliminating wasteful
activities that only complicate software development efforts." See the blog post for all kinds of details, ifs and buts.<br></div></div></div></blockquote><div>Hey Siebrand,</div><div><br></div><div>I am not entirely sure if Definition of Done is the best place to address non-functional requirements. As you know, DoD's are always team-specific: they reflect the consensus of the team and are tailored to the team's individual needs. Because DoD's are team-specific I worry that each team would have to learn the hard way the importance of (a set of) non-functional requirements.</div>
<div><br></div><div>Second, as mentioned in my original email, neither the customer nor the scrum team can/will/should do user acceptance testing for the non-functional requirements. So even when those non-functional requirements are part of the DoD, who is going to verify that?</div>
<div><br></div><div>Third, I do not think that all teams have all the competencies when it comes to assess non-functional requirements for their specific situation. I love that scrum places a lot of emphasis on growing a team but in our (=WMF) case that can be quite costly learning curve if certain non-functional requirements are not considered from the beginning (scalability, security, etc).</div>
<div>D</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div></div>Aside from these recurring requirements that are applied to deliverables for stories before they can be Done or "Ready for Signoff", you can have additional acceptance criteria in stories, the ones you call non-functional criteria, that may contribute to reducing technical debt.<br>
<br></div>The Language Engineering team has documented its DoD at <a href="https://www.mediawiki.org/wiki/Language_portal/Definition_of_Done" target="_blank">https://www.mediawiki.org/wiki/Language_portal/Definition_of_Done</a><br>
<div><div>
<br>[1] <a href="http://www.scrumalliance.org/community/articles/2008/september/what-is-definition-of-done-%28dod%29" target="_blank">http://www.scrumalliance.org/community/articles/2008/september/what-is-definition-of-done-%28dod%29</a><br>
<br></div><div>Cheers!<br><br>Siebrand<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div class="h5">On Mon, Sep 23, 2013 at 6:28 AM, Diederik van Liere <span dir="ltr"><<a href="mailto:dvanliere@wikimedia.org" target="_blank">dvanliere@wikimedia.org</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr">Heya,<br><div><br>Some recent discussions on different internal mailing lists seem to indicate to me that we need to think about a more holistic approach to our product development. In my mind, the following discussion threads point all in the same direction:<br>
1) Faidon -- Site issues, past two weeks & in progress (Ops list)<br>2) Erik -- Scrum of Scrums (Team practises list)<br>3) Tomasz - The Rule of Three (Team practises list)<br><br>One of the challenges that we face as we are adopting the scrum methodology is how we cope with 'non-functional requirements' [0]. Within the scrum methodology there is not a clear advocate for these non-functional requirements. I do not think that we have found yet a systematic solution for this problem. We are obviously not operating at a startup-scale so we must take non-functional requirements into consideration from the inception of a new feature/product. <br>
<br>One of the mistakes that the Analytics team made last year is that we focused too much on non-functional requirements and not enough on functional requirements. I think we are striking now a much better balance between these two set of requirements. In the area of non-functional requirements, the Analytics team has made two changes to how it's using the scrum methodology:<br>
1) We treat non-functional requirements as functional requirements and have the customer sign it off. For example, with our recent collaboration with Ops on developing varnishkafka we explicitly defined minimum performance in terms of processing speed of messages per second. <br>
2) At the epic [1] level, we define both 'business value' (why does the customer care about this feature) and 'platform capability' (how does this epic contributes to building out our total offering of solutions and we do not accrue technical debt along the way). This forces us to consider non-functional requirements from the get-go. <br>
<br>I can imagine that in the near-future, we will have to consider more non-functional requirements besides (for example) scalability and security. The following three come to mind (and sometimes we are already considering them on an individual product basis and this list will evolve):<br>
1) Mobile -- all products / features will work on mobile from the very first beta launch<br>2) Measurability -- measuring the efficacy of the feature and how to instrument it<br>3) Privacy by Design -- what data is stored and how can the person whose data we store manage this data<br>
<br>How to manage these non-functional requirements is an open question. Scrum subscribes to the view that the architecture is emergent but I am not convinced that is going to work well for us. I think we need a more holistic approach to discuss such requirements -- maybe we should treat Ops, Platform, Mobile and Analytics as the 'customers' for such non-functional requirements. It's not 100% scrum but then again scrum always emphasizes communication over process ;)<br>
<br>Curious to hear what other folks are thinking about this!<br><br>Best,<br><br>D<br><br>[0] BTW, I believe that non-functional requirements are a misnomer; I think that architectural requirement would be a better term. <br>
[1] The Analytics team defines an epic as a high level function that consists of either conceptually related user stories (End-to-End monitoring for different products) or a complex new feature 'Cohort Management' for Wikimetrics. <br>
</div></div>
<br></div></div>_______________________________________________<br>
teampractices mailing list<br>
<a href="mailto:teampractices@lists.wikimedia.org" target="_blank">teampractices@lists.wikimedia.org</a><br>
<a href="https://lists.wikimedia.org/mailman/listinfo/teampractices" target="_blank">https://lists.wikimedia.org/mailman/listinfo/teampractices</a><br>
<br></blockquote></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><br>-- <br>Siebrand Mazeland<br>Product Manager Language Engineering<br>Wikimedia Foundation<br><br>M: <a href="tel:%2B31%206%2050%2069%201239" value="+31650691239" target="_blank">+31 6 50 69 1239</a><br>
Skype: siebrand<br><br>Support Free Knowledge: <a href="http://wikimediafoundation.org/wiki/Donate" target="_blank">http://wikimediafoundation.org/wiki/Donate</a>
</font></span></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" target="_blank">https://lists.wikimedia.org/mailman/listinfo/teampractices</a><br>
<br></blockquote></div><br></div></div>