Re: Stories for a prototyping spike
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!