Where does Test Planing, Test Cases and Test Execution exist? More than often a dedicated set of resources are offered to provide this support whether it is internal or contracted out.

Thanks Deborah - that makes a lot of sense.

Matt wrote:
>It's still not clear to me how design development and core architecture can happen exactly in parallel, with *no* apparent dependency.

This takes careful planning. Ideally, while bas architecture is being driven out, the "deliverable customer value" being developed is something not dependent on this base architecture. Before the basic arch is in place, there could be low-risk work that can be usefully undertaken - it might need to be refactored later, but if it delivers enough value to the customer then by the time it is refactored maybe the refactor is already paid for?

Scrum is about balancing cost, risk and value to the customer to bring the most benefit to the enterprise. Huge up-front efforts with no evident value to the customer introduce large risks into the project: if the project gets cancelled when *just* the base architecture is done, the customer has absolutely no value for money spent.

>Is there a vertical time axis on this diagram I am missing, i.e. understanding happens before design, before development etc?

No, there's not a hard, "phasist" sequence of activities: the team is allowed to determine how to get the work done (a.k.a "emergent process"). Usually this involves understanding before coding :-) but it could happen in phases, or iteratively or chaotically... whatever works. And it might happen differently each Sprint. Scrum does not prescribe engineering practises, however it has been well combined with XP (and Lean Development too, I think) which do prescribe work processes. Scrum provides the "box" (the Sprint) and let's the team decide how to work within it.

Thanks, Ant, for the clear definitions of the terms used in the diagram. They are all helpful. I would, however, like add to your definition of "Sprint", as it is central. This term comes from the Scrum project management methodology described at ControlChaos.com and ScrumAlliance.com. Here is a classic definition:

Sprint: a short burst of work lasting approximately 30 days during which working software and other deliverables are built by an engineering team, as defined in the backlog determined at the beginning of the Sprint:
- A sprint is undertaken by a cross functional team consisting of no more than 9 members.
- An executable demonstrating the goal will be completed by the team during the sprint.
- The sprint team has final say in estimating and determining what they can accomplish during the sprint.
- Once the sprint is underway, new backlog cannot be added to the sprint.

I'm going to ask Deborah to answer that as she's the author of the diagram. I would have thought that this is a correct observation, although perhaps there's a lot of iteration across streams that's going on here that is not explicitly represented.

It's still not clear to me how design development and core architecture can happen exactly in parallel, with *no* apparent dependency.

Is there a vertical time axis on this diagram I am missing, i.e. understand happens before design, before development etc?

Or am I missing something else?

yours,

Ralph Wiggum

I'd like to get a clear definition/agreement of what each of these terms within the diagram means so I know our mental models are in sync. Here's my interpretation of what we're talking about here. Please add/correct/comment as necessary in the case that I have missed or misrepresented anything.

Sprint - a period of time in which to accomplish a set amount of broader project work (commonly referred to as 'breadth' and can encompass such work as research, audience definition, planning, overall architecture etc) and specific functionality (known as 'depth' and involves detailed work to actually deliver some component).

Understand - a body of work to make a clear picture of: the user's motivations, needs, goals, usage; the business goals, context and success critereon; any existing products with which the project deliverables will depend, cohabit or support; the competitive environment and marketplace in which the product will exist.

Design - a body of work to specify in varying levels of detail the way in which particular requirements will be met. This is done in a collaborative fashion across disciplines and outputs anything from, mood boards, brand mapping, use cases, system flows, task flows, technical and/or information architecture, wire-frames, finished UI visuals etc.

Develop - a body of work to implement the specification for features from the design work, manifesting itself in lines of code and/or database construction. This also should encompass functional testing so that units of code are reliable under the conditions in which they will eventually be released.

Core Architecture - a body of work to define the underpinning code-base, database construction, metadata structure on which the entire system will be based.

Requirements - a term used to describe what is required of the system. This is not as specific to define features as such, but to describe what is needed so as to allow for different solutions to be explored.

Release - that magical point where the project reaches a level of completion satisfactory to launch it to the paying/viewing public. Work specific to this end is usually directed toward supporting the administrators and/or end users of the product.