Stories for a prototyping spike
- We are about to kick off a prototyping spike after we complete our
current sprint. The purpose of the spike is to do some real learning
and sort out a generalized architecture model. We are looking for a
breadth first set of buckets to drop our implementations of the next
set of stories. The alternative is BDUFing our design, or depth first
implementing 1 component at a time - this is all bad in our view.
The question is - for our development spike, what stories make sense?
This product itself is a prodyuct that serves developers. All of the
stories for this product are "as a developer I can .. so that". The end
users are developers - they are who we deliver value to. We make them
deliver their solutions faster, better, more uniformly, etc. We will
not 'close' any of our user effecting stories in this sprint. We have
been tossing around some stories for the sprint, but it does not feel
quite natural as we are only delivering a set of
architectural "buckets" that are mostly NOT implemented....
Any thoughts would be appreciated.
- Why is implementing 1 component at a time a bad thing?Usually in Scrum you want to work on a vertical slice of the application, because you want to demonstrate end-user functionality. Why is this not a good thing for you? How do you know you are developing your architecture correctly if you're not exposing end-user functionality? If you develop your architecture first in total -- what happens when you get to the end-user functionality and realize that the architecture you built will not support what it is they need or want?Also you need to demonstrate your stories at the end of the Sprint. If you are not closing them in this Sprint what are you doing, how are you defining what done is?A little worried,NicholasOn Apr 28, 2007, at 12:30 PM, chrisdonnan wrote:
Actually, I think you are missing me. I do appreciate the comment and believe you should never implement 1 component at a time...
I have ~20 teams of software developers building front office trading applications in one of the big investment banks. These ~20 teams use a developer-centric framework. This framework/ suite DELIVERS VALUE to the software developers in order to enable them to deliver faster and it all looks/ feels the same. All the user stories are phrased in "as a developer, I can do X, so that Y". Think of how a software firm like microsoft would have to write their user stories (they do in fact do something similar to user stories they call them some type of scenario that is done BEFORE any API is written, before TDD). These are not "developer tasks" We are delivering "front to back" functionality through all layers of this particular application framework/ suite.
The aforementioned ~20 teams have their own backlogs that have stories like "as a trader, I can so that..", or "as a marketer .", etc. My point is that we are very much slicing the work vertically. The application framework/ suite I am referring to is itself full of "components" that we do NOT implement 1x1. This application delivers stories to other developers. We DO demonstrate features that were implemented "straight through" several components.
The purpose of this post however is more on "design". It is common to have a "spike" where you "flesh out" your design. You do not want to BDUF a design, but in a nontrivial (millions of lines of code) type application, you MUST have some type of cohesive set of albeit evolutionary architecture. We DO shoot for emergent design, but there must be more stable boundaries between applications, services, subsystems at the global investment bank level, else you would have to "refactor the enterprise" and it would be costly.
So the goal of a "spike" is to look at a number of stories that we have high in our queue and to try to sort out some potential "higher level" basic component "buckets". For example, we might try 5 ways to implement the 1st 3 stories. You go "breadth first" not depth first and come out with an "architectural runway"( see scaling software agility book for concept) or "component buckets". These are the basic buckets into which your vertically sliced story implementations will fall or a loose architecture to keep you from refactoring the enterprise frequently.
My current thought is that we are going to have a normal 1 month sprint. The 1st 2 weeks will be a "design spike" and the 2nd 2 weeks will be implementing the top N stories according to the "buckets" we define. We will then have demonstable behavior out the end and we would have had a bit of extended design effort that will drive a few iterations. This concept of design spikes in a sprint is also discussed in that "scaling software agility" and I discuss briefly this "bucket" architecture idea at my blog I called it the "plinko model of software architecture" here :
I would never allow the entire architecture of any app to be developed "up front" as you say, but I would also be damaging the business by having no generalized architecture that someone else could rely on to some level. EVERY BIT of architecture MUST be fleshed out in the context of implementing end user functionality, else it is moot.
As some of my earlier comments allude to this is all done at a huge scale and at very large scale actual applications. The generalized pattern of "vision and prior experience + design spikes -> implementation" is a common one that we use on the micro level. Applying this on the larger scale must also happen, but it must also be time boxed etc, as per the rest of our empirical process (scrum).
My basic question here was really "should we have stories for the design spike itself". I think I answered my own question working with this team, with the answer that we would spend the 1st part of the sprint in "spike mode" looking at lots of our stories and doing quick shots at implementing them in a few different ways. The 2nd part of the sprint would be delivering the top N stories. It was more puzzling to me if I was to do a whole sprint with no outcomes other than some basic design spike. With my current plan of 1/2 half spike, 2nd half using the outcome of that do deliver features... it makes a bit more sense. "Classical scrum" does not address certain "scale out issue", I think this is one of those areas. This is why I try to always "check my thoughts" when I am doing things to scale the practices.
Scaling scrum is an interesting challenge!