[teampractices] Towards more holistic product/feature development

[Siebrand Mazeland (WMF)]

Hey Diederik,

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.

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.

The Language Engineering team has documented its DoD at
https://www.mediawiki.org/wiki/Language_portal/Definition_of_Done

[1]
http://www.scrumalliance.org/community/articles/2008/september/what-is-definition-of-done-%28dod%29

Cheers!

Siebrand


On Mon, Sep 23, 2013 at 6:28 AM, Diederik van Liere <dvanliere at wikimedia.org
> wrote:

> Heya,
>
> 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:
> 1) Faidon -- Site issues, past two weeks & in progress (Ops list)
> 2) Erik -- Scrum of Scrums (Team practises list)
> 3) Tomasz - The Rule of Three (Team practises list)
>
> 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.
>
> 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:
> 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.
> 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.
>
> 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):
> 1) Mobile -- all products / features will work on mobile from the very
> first beta launch
> 2) Measurability -- measuring the efficacy of the feature and how to
> instrument it
> 3) Privacy by Design -- what data is stored and how can the person whose
> data we store manage this data
>
> 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 ;)
>
> Curious to hear what other folks are thinking about this!
>
> Best,
>
> D
>
> [0] BTW, I believe that non-functional requirements are a misnomer; I
> think that architectural requirement would be a better term.
> [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.
>
> _______________________________________________
> teampractices mailing list
> teampractices at lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/teampractices
>
>


-- 
Siebrand Mazeland
Product Manager Language Engineering
Wikimedia Foundation

M: +31 6 50 69 1239
Skype: siebrand

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wikimedia.org/pipermail/teampractices/attachments/20130923/418753b1/attachment-0001.html>