Design Spike
Hi,
As part of our next sprint, our team is being asked to collaborate with another team (2x team members allocated from each team) to deliver a design Spike.
Here's the stories we got:
AS A Business Analyst I NEED an overall design for the project phase SO THAT Engineering can build it
With acceptance criteria of: Documented design providing the architecture and physical design that will be used to deliver the project phase - time boxed activity limited to 2 engineers for an iteration.
This doesn't meet INVEST criteria, but the get out clause from our BA is "its a Spike, so of course we don't have a clear outcome"
I'm very uneasy about this approach, as I believed that we had ditched BUFD with waterfall. My understanding was that we'd break off part of the big picture and design and engineer it within a sprint, returning and enhancing if needed. If design decisions were found to be flawed later, we'd go back and refactor.
Is there a right or wrong way of incorporating design elements into a sprint? Am I just being fussy?
Thanks
Col
Stories are really supposed to be functional with business value, so your concern is justified.
We have used technical stories, such as "As customer, I can send data via web services...." because we needed to build integrations to/from an ERP and I couldn't figure out a way to phrase it as functional/user. They should be the exception, not the rule.
For the spike justification, show him this: http://blog.agilebuddy.com/2009/11/what-is-a-spike-in-scrum.html, from a "agile spike" internet search. Spikes IMO are more Proof of Concept than design.
The BA is the Product Owner? Try to find out (in a collaborative way) WHY he/she needs the overall design. What business value does it provide? Is it because there are interdependencies between the groups (which would be a good reason but maybe there's another way to accomplish that beyond document everything).
I mean, "Working software over comprehensive documentation" is in the agile manifesto...
OTOH, when there are dependencies with other teams, my team expects some kind of documentation before they start working on it, so the pieces work together. In our case it's an integration specification (in web services example request/response is defined before coding, although it can and does change during implementation).
> AS A Business Analyst I NEED an overall design for the project phase SO THAT Engineering can build it
Why would a Business Analyst need a design? For that matter, why would a Business Analyst need Engineering to build anything? Moreover, where does any of this fit in to the value stream of creating a potentially releasable increment by the end of this Sprint?
There's something screwy with role definitions and product ownership here.
> ...time boxed activity limited to 2 engineers for an iteration
It sounds like 2 engineers are being taken out of each team for this work. If so, that won't make an iteration. Team composition and identity is being interfered with (presumably by an external authority), the ability to inspect and adapt the team process will be compromised, and the metrics gathered will be essentially incomparable and meaningless. That's not an iteration. It's breaking up Scrum teams by the commandeering and cynical misuse of agile language.
So yes, you are right to feel uneasy.
Thanks guys.
I've managed to rework the "story" into something much more palatable. Namely 2 spikes.
One doing some inspection of current functionality and mapping it onto a desired process at a v.high level.
One concerns proposing an approach at a high level to fill the gaps.
Its not perfect, and I'm actively trying to make sure this doesn't become the norm.
The BA is the Product Owner? Try to find out (in a collaborative way) WHY he/she needs the overall design. What business value does it provide? Is it because there are interdependencies between the groups (which would be a good reason but maybe there's another way to accomplish that beyond document everything).
I mean, "Working software over comprehensive documentation" is in the agile manifesto...
OTOH, when there are dependencies with other teams, my team expects some kind of documentation before they start working on it, so the pieces work together. In our case it's an integration specification (in web services example request/response is defined before coding, although it can and does change during implementation).
Newbie here too! Nice to meet everyone!
Hello all, I am new on this forum and I believe it will be a wonderful experience here.