Open Source Ecology - User contributions [en]

Weekly Update Blog Post

2012-03-17T22:18:26Z

Mia Van Meter:

We are looking for somebody to assist with a weekly video blog post for Open Source Ecology. This post will be an edit from ongoing video footage from the [[Founder]] and other team members. Content for this will come from the [[Marcinose_YouTube]], other media repositories ([[Team Wikispeed YouTube Channel]], [[Brianna Kufa Log]], [[Aaron_log]], [[Status Briefs]]), email communication, and regular (2x per week) consultation with [[Founder]] to provide accurate and timely transparency on the evolution of the project.

Tasks + Responsibilities:
*15 minute check-in with key project developers including founder (1.5 hours per week)
*composition of blog post and publishing on OSE Blog (2.5 hours per week)
**includes embed of video and pictures
*Collaboration with other OSE bloggers and video editors as needed to fulfill above tasks
*Process facilitation using [[Scrumy]] as the agile collaboration platform.
*Contact [[mailto:recruiting@opensourceecology.org]]
[[Category:Recruiting]]

Definition of Done for the Blog post.
-- how a blog post can increase the experience of value for the whole organization

Bill Of Materials

2012-03-16T05:47:23Z

Mia Van Meter:

For Power Cube

==Steel==

{| border="1" align="center" cellspacing="0" cellpadding="2"
|-
!scope="col"| Type
!scope="col"| Dimensions
!scope="col"| Length
|-
!scope="row"| Angle
|1/4" x 2" x 2"
|408" (33')
|-
!scope="row"|Plate
|1/4" x 8"
|14"
|-
!scope="row"|Plate
|1/4" x 2"
|0?"
|-
!scope="row"|Plate
|1/4" x 6"
|6"
|-
!scope="row"|Plate
|1/4" x 4"
|14"
|-
!scope="row"|Plate
|3/8" x 4"
|54"
|-
!scope="row"|Tube
|1/4" x 6" x 12"
|54"
|-
!scope="row"|Black Pipe
|2 1/2" ID
|1/2"
|-
!scope="row"|Expanded Steel
|1/4" x 27"
|27"
|}

==Parts==

{| border="1" align="center" cellspacing="0" cellpadding="2"
|-
!| Name
!| Qty
!| Desc
!| Source
!| Part #
!| Ref. Price
|-
| Engine
| 1
| Briggs & Stratton 28 HP Engine
| [[http://SmallEngineSuppliers.com Small Engine Suppliers]]
| 49M777
| $699.95
|-
| Muffler
| 1
| Muffler - Above plane
| [[http://SmallEngineSuppliers.com Small Engine Suppliers]]
| MUF0626
| $72.95
|-
| Hydraulic Pump
| 1
| 0.98 cu in
| [[http://SurplusCenter.com Surplus Center]]
| 9-4848-E
| $105.99
|-
| Strainer
| 1
| 1 1/2" NPTM to 1" NPTF 14 GPM Tank Strainer
| [[http://SurplusCenter.com Surplus Center]]
| 9-7290-100
| $19.95
|-
| Filter
| 1
| 10 Micron 3/4" NPT Female
| [[http://SurplusCenter.com Surplus Center]]
| 9-059
| $17.95
|-
| Hose Barb
| 1
| 1" Hosebarb to SAE 16M
| [[http://SurplusCenter.com Surplus Center]]
| 9-4604-16-16
| $7.19
|-
| Hose Barb
| 1
| 1" x 1" NPTM
| [[http://SurplusCenter.com Surplus Center]]
| 9-4404-16-16
| $6.00
|-
| Connector
| 1
| JIC 12M x 3/4" NPTM Connector
| [[http://SurplusCenter.com Surplus Center]]
| 9-2404-12-12
| $2.55
|-
| Bushing
| 1
| 3/4" Male x 1/4" Female NPT
| [[http://SurplusCenter.com Surplus Center]]
| 9-5406-12-4
| $2.50
|-
| Elbow
| 3
| 3/4" x 3/4" Female NPT
| [[http://SurplusCenter.com Surplus Center]]
| 9-5500-12-12
| $5.00
|-
| Tee
| 1
| 3/4" x 3/4" x 3/4" NPTF Tee
| [[http://SurplusCenter.com Surplus Center]]
| 9-5605-12-12-12
| $7.00
|-
| Nipple
| 3
| 3/4" x 3/4" Male NPT Nipple
| [[http://SurplusCenter.com Surplus Center]]
| 9-5404-12-12
| $2.65
|-
| Tank Breather
| 1
| 3/4" NPT Plastic Tank Breather
| [[http://SurplusCenter.com Surplus Center]]
| 9-7957-12
| $4.49
|-
| Rubber Mount
| 4
| 1.50" O.D. Rubber Vibration-Isolation Mount
| [[http://SurplusCenter.com Surplus Center]]
| 1-3235
| $0.39
|-
| Weld-In Flange
| 1
| 1 1/2" NPT Forged Weld-In Flange
| [[http://SurplusCenter.com Surplus Center]]
| 9-7843-24
| $4.50
|-
| Quick Coupler
| 3
| 1/4" NPT Quick Coupler
| [[http://SurplusCenter.com Surplus Center]]
| 9-6314
| $17.95
|-
| Weld-In Flange
| 3
| 3/4" NPT Forged Weld-In Flange
| [[http://SurplusCenter.com Surplus Center]]
| 9-7843-12
| $2.75
|-
| Quick Coupler
| 1
| 3/4" NPT Quick Coupler S40-6 F/F
| [[http://SurplusCenter.com Surplus Center]]
| 928-C
| $25.95
|-
| Elbow
| 2
| JIC 12M x 3/4" NPTM 90 Elbow
| [[http://SurplusCenter.com Surplus Center]]
| 9-2501-12-12
| $5.95
|-
| Connector
| 2
| JIC 12M x 3/4" NPTM Connector
| [[http://SurplusCenter.com Surplus Center]]
| 9-2404-12-12
| $2.95
|-
| Plug
| 1
| 1/4" NPT Plug
| [[http://SurplusCenter.com Surplus Center]]
| 9-5406-P-4
| $0.40
|-
| Elbow
| 1
| 3/4 NPTM x 1/2 NPTF 90 SWIVEL
| [[http://SurplusCenter.com Surplus Center]]
| 9-1501-12-8
| $6.20
|-
| Hose
| 1
| 1/2" X 12" 1/2 NPTM X 1/2 NPTM 3000 PSI HYD HOSE
| [[http://SurplusCenter.com Surplus Center]]
| 905-1212
| $6.00
|}

Rugby approach: development overlaps across several stages of development

2012-03-11T19:18:56Z

Mia Van Meter:

Ragarding product development methodology, several timing approaches can be applied for development steps. [[Extreme Manufacturing]] relies on maximum overlap of stages and constant learning interplay between the stages.

From Harvard Business Review, Janauary-February 1986 - [http://mis.postech.ac.kr/class/MEIE780_AdvMIS/paper/part3/32_The%20new%20product%20development%20game.pdf]:

[[Image:Rugby.jpg]]

Under the rugby approach, the product develop-
ment process emerges from the constant interaction
of a hand-picked, multidisciplinary team whose
members work together from start to finish. Rather
than moving in defined, highly structured stages, the
process is born out of the team members’ interplay
(see Exhibit 1). A group of engineers, for example,
may start to design the product (phase three) before
all the results of the feasibility tests (phase two) are
in. Or the team may be forced to reconsider a decision
as a result of later information. The team does not
stop then, but engages in iterative experimentation.
This goes on in even the latest phases of the develop-
ment process.

'''Exhibit 1''' illustrates the difference between the
traditional, linear approach to product development
and the rugby approach. The sequential approach (often referred to as the Waterfall method),
labeled type A, is typified by the NASA-type PPP
system. The overlap approach is represented by type
B, where the overlapping occurs only at the border of
adjacent phases, and type C, where the overlap ex-
tends across several phases. We observed a type B
overlap at Fuji-Xerox and a type C overlap at Honda
and Canon.

=Appication=
leading
companies show six characteristics in managing their
new product development processes:
#Built-in instability
#Self-organizing project teams
#Overlapping development phases
#“Multilearning”
#Subtle control
#Organizational transfer of learning

[[Category:XM]]

Scrum

2012-03-06T20:59:19Z

Mia Van Meter: /* Adapting Scrum to Hardware Technologies */

Definition: '''[[wikipedia:Scrum (development)|Scrum]]''' is an iterative and incremental methodology for software projects and product- or application-development. It is also one of the variants of [[wikipedia:agile software development|agile software development]] methodologies.

==Why would a development team use Scrum?==

As demonstrated by high-powered software teams around the world, the Scrum process can increase a development team's efficiency dramatically. In recent years, some Scrum coaches (Scrum Masters) can consistently get development teams to be six times more efficient, and it is becoming almost unremarkable for a Scrum Master to kick a team into a productive state 15 times more productive than in their pre-Scrum days.

Scrum is essentially a double handful of rules for how a team should work together, and how they should be managed. Underneath those rules is a profound understanding of human nature. What motivates us? That is the essential question which Scrum answers. Scrum rules are designed to instill ownership, motivation, and creative problem-solving in team members. The dramatic results of a well-functioning Scrum team come from the synchronistic multiplying effect of a group of developers working “in the flow.” [http://en.wikipedia.org/wiki/Jeff_Sutherland/ Jeff Sutherland], one of the creators of Scrum, refers to these as “activated” teams.

Following [http://en.wikipedia.org/wiki/Lean_software_development/ Lean] development principles, the rules of Scrum are stripped down to the essentials. One of the implications of this is that teams must adopt all the Scrum rules in order to get Scrum results. Jeff Sutherland's favorite lecture topic seems to be “Scrumbutt.” This occurs when teams say, “Yes, we're doing Scrum, but...” and explain an aspect of Scrum they decided not to implement. According to Sutherland, you cannot get dramatic results unless you are pretty much a Scrum purist. That said, Scrum can “wrap around” other software development process technologies like, for example, XP or Lean. It's not essential to understand those technologies fully, for our purposes, but they are mentioned in the discussion on this page.

The most relevant question for a project like OSE is – is Scrum applicable outside the software development world? This is the answer that Joe Justice and the WikiSpeed team answer with a resounding “Yes!” In the 10-minute TEDX talk below, he explains briefly how the WikiSpeed Team, a collection of 44 volunteers in 4 countries, in three months used Scrum and associated processes to design and build a road-certifiable 4-person commuter car that can get over 100 miles per gallon in standard EPA road tests. The relevance of this to OSE is obvious – a distributed team of volunteers co-developing revolutionary hardware, sound familiar? It's well worth your while to spend a few hours absorbing the information on Scrum that this page points to, and to help explore its relevance for OSE in general, and the GVCS in particular.

In this video, Joe Justice, of WikiSpeed, explains the process his all-volunteer design team used to exceed expectations in their fuel-efficient car design.

<html><iframe width="300" height="182" src="http://www.youtube.com/watch?v=x8jdx-lf2Dw" frameborder="0" allowfullscreen></iframe></html>

.
.

.
.

==What is Scrum?==

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/watch?v=Q5k7a9YEoUI" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
The video above is a great first introduction to Scrum! It's fast paced, and the graphics easily convey the important information.

Of course, like any single Scrum coach, this one has his own take on Scrum, and in some instances it's likely that OSE Scrum will be different.

To review his core concepts:

Roles: Product Owner, Scrum Master, Team Members (developers, testers, customers)

Release Planning:
*Product Backlog– Estimate for each feature wanted in product.
*Release Backlog
*plan 4-12 Sprints – a substantive back log to a ship-ready state
*Sprint Backlog

Burndown Chart – day by day measure of the amount of work left in a Release, or Sprint

Bugs – have a separate Defect Backlog. Resolve bugs within the Sprint.

Daily Scrum – short, standing, identify bugs.

So that video is a great introduction to Scrum, but how would we actually get started?

The Scrum process starts with the Product Owner. They are responsible for creating the Product Backlog, creating the Development Team, and for providing the Team with the tools necessary for them to work. The Scrum Master helps the Product Owner with these tasks.

===Sprint ZERO===

To get ready for the first development Sprint, the Product Owner and the Scrum Master need to meet together, and with the Team, and do some initial preparation. The amount of time spent on Sprint Zero should be limited, and agreed upon in advance. Unfinished preparation can be added to the Product Backlog when Sprint Zero is finished. Additionally, the task of adding to the Product Backlog, and refining features that are down the road a bit, will be ongoing tasks for the Product Owner.

The most important outcome of Sprint Zero is to create understanding about the value of the work. Given that OSE might choose to have a team (Scrum) of Product Owners, it could make implementation more clear if the business values we are creating are explicitly ranked. Usually the process of identifying and clarifying the business value is held more distantly from the Team. In the case of OSE, it seems likely that a group of people will be determining the relative priorities of our business values, and the relative rankings of the features that we're planning on creating.

Here are some further questions to be taken up during Sprint Zero:
* Do we have the right people with the right skills? Is there a need for consultants, etc.?

* Given the Epic User Stories, the values, and the efinitions of done, what sort of work place, tools and technology set up are indicated?

* What is the general approach we are taking? What will be the length of our Sprints? What is the Road Map -- the key release points? How many teams will there be? If there are multiple teams, how will the Scrum Masters and the Product Owners from the multiple teams work together?

At the end of Sprint Zero, the Product Backlog must contain enough prioritized Stories to fill at least the first Release. Ideally, there would be enough Stories for two or three releases, so that the broad outlines of the technology and personnel needed can be understood.

Here's a possible outline for Sprint Zero:
Determine the length of sprints
Identify business value (the criteria to prioritize Stories)
Create epics. Prioritize epics (consider relative business value)
For the highest priority epic, turn the epic into stories
Prioritize the stories (consider relative business value)
For each story, create a definition of done
Create a team(s) workspace(s), and provide appropriate technology
Configure the team(s)

The following sections explain the Scrum terms needed to understand Sprint Zero work.

===User Stories===

We've been talking about ranking the features that make up the Product Backlog. In Scrum, these features are called Stories. There is an art to defining a Scrum Story, as you might imagine. Stories often take this form:

As _[User]_____, I want _[feature]_______, so that __[value]______.

An example:

* As a fabricator making a CNC Torch Table, I want complete and accurate CAD drawings, so that my efforts will result in a well-functioning machine.

Because the User is included in defining the feature, these are known as User Stories. The following video explains a good way to evaluate and improve User Stories, which are the list of features that make up the Product Backlog.

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=L_NyCczp0Fk&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.

To review the key ideas of the video:

'''Independent''' – dependencies among or between Stories need to be identified, eliminated, or tracked. An example of dependency: the training video for making a machine cannot be made until the machine is designed.
'''Negotiable''' – the Product Owner and the Team co-create the value and attributes of features (Stories)
'''Valuable''' – all Stories are connected directly to business value.
'''Estimable''' – the Team estimates the size of the Stories relative to each other.
'''Small''' – an important concept is raised here. Stories that are coming up in priority in the first or second Release should be small enough to be finished in one Sprint. Stories that are being implemented later can be large (Epics – more on this below).
'''Testable''' – knowing how we will know the Story is done, also called knowing the Definition of Done.

This review of the qualities of a good User Story gives some idea of the work to be done during Sprint Zero, while the User Stories are created, combined in one list, and then prioritized to make up the Product Backlog.

===Epic User Stories===

During Sprint Zero, the Product Owner will create a list of Epics. Epics are very large Stories. An example:
* As OSE, I want complete training materials in English for the 50 tools in GVCS on DVD, so that anyone with moderate experience in fabrication, and with access to the necessary tools and materials, can fabricate any of the 50 tools.

The list of Epics doesn't have to be exhaustive, but it should be thoroughly discussed and described, using the criteria for Stories developed in the video above.

===Definition of Done===

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=9FnZsaRujpw&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
NOTE -- this video is LOUD!

Review of the main concepts of the video:

This video is from Agile; Scrum is one form of Agile. So in this video you don't see mention of a Scrum Master. Instead they talk about a Team Lead. However, the content on Definition of Done is relevant for OSE.

In this video he is discussing creating the Definition of Done at the Team level. The Product Owner needs to first supply the Team with an initial Definition of Done feature by feature. The Product Owner's Definition of Done revolves around the What (and explains the Why). The Team's Definition of Done defines the How.

One value of this video is that it stresses how all members of a multi-functional Team get involved in creating the Definition of Done. It is crucial that this Definition is agreed to by everyone on the Team. When the Team commits to the work included in a Release, and in each Sprint, they are doing so based on the agreed on Definition of Done for each Story.

There is quite a bit of excess jargon in this video, but have patience, and relate it to GVCS. For example, we not only need to have the machine design "done," but also CAD drawings, an instructional video, and many other instructional components. Unifying the release and "done-ness" of all of these is what seems like the best, and most radical!, contribution Scrum can make to GVCS. These underlying points of “What is Done?” are crucial for us to understand the work that is needed in Sprint Zero.

==OSE [[GVCS]] Scrum==

OSE already has many of the pieces necessary to Scrum. There has been a lot of thought put into how to maximize the value of the project, the resulting list of GVCS machines, and the step-by-step process needed make them. All the work that has already been done would be used as the ground work for a [[#Sprint ZERO]].

The main question seems to be, who would do the work of Sprint Zero for OSE. It seems that [[Marcin Jakubowski|Marcin]] needs to be centrally involved in the first three steps of Sprint Zero. In addition to Marcin for those first three steps, at minimum a Scrum Master would be needed. This is when the input Marcin brought back from TED in March (redistributing economic justice?) will be integrated into the current vision.

For the next two steps, turning the highest priority Epic into Stories, and prioritizing the Stories, another person(s) could step in for Marcin, if that seems best for OSE.

The need for Subject Matter Experts arises in the next step, creating the initial Definition of Done for each Story. An example of this would be creating standards for instructional videos, and ways to objectively measure if the instructional video for a certain machine meets those standards.

The real creative work needed to get ready for OSE Scrum involves understanding the incremental Releases, in other words, getting a vision of the order in which OSE "products" (the plans and documentation for each machine) will appear in the Product Backlog. The current list of [[GVCS Development Template#Process|31 steps]] needs to be reconfigured into Stories, and understood in terms of interim products that can be brought to the state of Done. The dependencies among the steps need to be charted out. This process will be used over and over, so getting it well understood, with really clear Definitions of Done, will help tremendously. The order in which the Stories from the 31 Steps appear will be a combination of the chronological dependencies of the steps, and the relative value of the Stories.

===Adapting Scrum to Hardware Technologies===

(Dear Reader: the ideas from the Maccherone blog are incompletely represented here. See the link in Notes for a valuable perspective.)

Although there are likely more dependencies among Stories in hardware development, in Scrum you plan around these when planning a Release, and the Sprints within the Release.

In contrast to software development teams, hardware development teams may find that they need to consult technical specialists regularly to complete their work. The Scrum approach to this would involve seeing the specialists as outside suppliers. In general, however, the cross-functional training that occurs within the team, as people work in pairs, and as team members reach outside their comfort zone by selecting the Story with the highest priority, strengthens the team.<ref>Maccherone, Larry. [http://maccherone.com/larry/2010/02/23/top-10-questions-when-using-agile-on-hardware-projects/ Top 10 questions when using Agile on hardware projects]. 23 February 2010. Retrieved 1 March 2012.</ref>

==Notes==
<references />

==See Also==

* [http://www.scrumhw.org/ Scrum for Hardware Product Development] ''Bringing Scrum to the Hardware Product Development Community''
* [http://maccherone.com/larry/2010/02/23/top-10-questions-when-using-agile-on-hardware-projects/ Top 10 questions when using Agile on hardware projects]

[[Category:Project Management]]

Scrum

2012-03-06T20:58:57Z

Mia Van Meter: /* Adapting Scrum to Hardware Technologies */

Definition: '''[[wikipedia:Scrum (development)|Scrum]]''' is an iterative and incremental methodology for software projects and product- or application-development. It is also one of the variants of [[wikipedia:agile software development|agile software development]] methodologies.

==Why would a development team use Scrum?==

As demonstrated by high-powered software teams around the world, the Scrum process can increase a development team's efficiency dramatically. In recent years, some Scrum coaches (Scrum Masters) can consistently get development teams to be six times more efficient, and it is becoming almost unremarkable for a Scrum Master to kick a team into a productive state 15 times more productive than in their pre-Scrum days.

Scrum is essentially a double handful of rules for how a team should work together, and how they should be managed. Underneath those rules is a profound understanding of human nature. What motivates us? That is the essential question which Scrum answers. Scrum rules are designed to instill ownership, motivation, and creative problem-solving in team members. The dramatic results of a well-functioning Scrum team come from the synchronistic multiplying effect of a group of developers working “in the flow.” [http://en.wikipedia.org/wiki/Jeff_Sutherland/ Jeff Sutherland], one of the creators of Scrum, refers to these as “activated” teams.

Following [http://en.wikipedia.org/wiki/Lean_software_development/ Lean] development principles, the rules of Scrum are stripped down to the essentials. One of the implications of this is that teams must adopt all the Scrum rules in order to get Scrum results. Jeff Sutherland's favorite lecture topic seems to be “Scrumbutt.” This occurs when teams say, “Yes, we're doing Scrum, but...” and explain an aspect of Scrum they decided not to implement. According to Sutherland, you cannot get dramatic results unless you are pretty much a Scrum purist. That said, Scrum can “wrap around” other software development process technologies like, for example, XP or Lean. It's not essential to understand those technologies fully, for our purposes, but they are mentioned in the discussion on this page.

The most relevant question for a project like OSE is – is Scrum applicable outside the software development world? This is the answer that Joe Justice and the WikiSpeed team answer with a resounding “Yes!” In the 10-minute TEDX talk below, he explains briefly how the WikiSpeed Team, a collection of 44 volunteers in 4 countries, in three months used Scrum and associated processes to design and build a road-certifiable 4-person commuter car that can get over 100 miles per gallon in standard EPA road tests. The relevance of this to OSE is obvious – a distributed team of volunteers co-developing revolutionary hardware, sound familiar? It's well worth your while to spend a few hours absorbing the information on Scrum that this page points to, and to help explore its relevance for OSE in general, and the GVCS in particular.

In this video, Joe Justice, of WikiSpeed, explains the process his all-volunteer design team used to exceed expectations in their fuel-efficient car design.

<html><iframe width="300" height="182" src="http://www.youtube.com/watch?v=x8jdx-lf2Dw" frameborder="0" allowfullscreen></iframe></html>

.
.

.
.

==What is Scrum?==

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/watch?v=Q5k7a9YEoUI" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
The video above is a great first introduction to Scrum! It's fast paced, and the graphics easily convey the important information.

Of course, like any single Scrum coach, this one has his own take on Scrum, and in some instances it's likely that OSE Scrum will be different.

To review his core concepts:

Roles: Product Owner, Scrum Master, Team Members (developers, testers, customers)

Release Planning:
*Product Backlog– Estimate for each feature wanted in product.
*Release Backlog
*plan 4-12 Sprints – a substantive back log to a ship-ready state
*Sprint Backlog

Burndown Chart – day by day measure of the amount of work left in a Release, or Sprint

Bugs – have a separate Defect Backlog. Resolve bugs within the Sprint.

Daily Scrum – short, standing, identify bugs.

So that video is a great introduction to Scrum, but how would we actually get started?

The Scrum process starts with the Product Owner. They are responsible for creating the Product Backlog, creating the Development Team, and for providing the Team with the tools necessary for them to work. The Scrum Master helps the Product Owner with these tasks.

===Sprint ZERO===

To get ready for the first development Sprint, the Product Owner and the Scrum Master need to meet together, and with the Team, and do some initial preparation. The amount of time spent on Sprint Zero should be limited, and agreed upon in advance. Unfinished preparation can be added to the Product Backlog when Sprint Zero is finished. Additionally, the task of adding to the Product Backlog, and refining features that are down the road a bit, will be ongoing tasks for the Product Owner.

The most important outcome of Sprint Zero is to create understanding about the value of the work. Given that OSE might choose to have a team (Scrum) of Product Owners, it could make implementation more clear if the business values we are creating are explicitly ranked. Usually the process of identifying and clarifying the business value is held more distantly from the Team. In the case of OSE, it seems likely that a group of people will be determining the relative priorities of our business values, and the relative rankings of the features that we're planning on creating.

Here are some further questions to be taken up during Sprint Zero:
* Do we have the right people with the right skills? Is there a need for consultants, etc.?

* Given the Epic User Stories, the values, and the efinitions of done, what sort of work place, tools and technology set up are indicated?

* What is the general approach we are taking? What will be the length of our Sprints? What is the Road Map -- the key release points? How many teams will there be? If there are multiple teams, how will the Scrum Masters and the Product Owners from the multiple teams work together?

At the end of Sprint Zero, the Product Backlog must contain enough prioritized Stories to fill at least the first Release. Ideally, there would be enough Stories for two or three releases, so that the broad outlines of the technology and personnel needed can be understood.

Here's a possible outline for Sprint Zero:
Determine the length of sprints
Identify business value (the criteria to prioritize Stories)
Create epics. Prioritize epics (consider relative business value)
For the highest priority epic, turn the epic into stories
Prioritize the stories (consider relative business value)
For each story, create a definition of done
Create a team(s) workspace(s), and provide appropriate technology
Configure the team(s)

The following sections explain the Scrum terms needed to understand Sprint Zero work.

===User Stories===

We've been talking about ranking the features that make up the Product Backlog. In Scrum, these features are called Stories. There is an art to defining a Scrum Story, as you might imagine. Stories often take this form:

As _[User]_____, I want _[feature]_______, so that __[value]______.

An example:

* As a fabricator making a CNC Torch Table, I want complete and accurate CAD drawings, so that my efforts will result in a well-functioning machine.

Because the User is included in defining the feature, these are known as User Stories. The following video explains a good way to evaluate and improve User Stories, which are the list of features that make up the Product Backlog.

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=L_NyCczp0Fk&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.

To review the key ideas of the video:

'''Independent''' – dependencies among or between Stories need to be identified, eliminated, or tracked. An example of dependency: the training video for making a machine cannot be made until the machine is designed.
'''Negotiable''' – the Product Owner and the Team co-create the value and attributes of features (Stories)
'''Valuable''' – all Stories are connected directly to business value.
'''Estimable''' – the Team estimates the size of the Stories relative to each other.
'''Small''' – an important concept is raised here. Stories that are coming up in priority in the first or second Release should be small enough to be finished in one Sprint. Stories that are being implemented later can be large (Epics – more on this below).
'''Testable''' – knowing how we will know the Story is done, also called knowing the Definition of Done.

This review of the qualities of a good User Story gives some idea of the work to be done during Sprint Zero, while the User Stories are created, combined in one list, and then prioritized to make up the Product Backlog.

===Epic User Stories===

During Sprint Zero, the Product Owner will create a list of Epics. Epics are very large Stories. An example:
* As OSE, I want complete training materials in English for the 50 tools in GVCS on DVD, so that anyone with moderate experience in fabrication, and with access to the necessary tools and materials, can fabricate any of the 50 tools.

The list of Epics doesn't have to be exhaustive, but it should be thoroughly discussed and described, using the criteria for Stories developed in the video above.

===Definition of Done===

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=9FnZsaRujpw&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
NOTE -- this video is LOUD!

Review of the main concepts of the video:

This video is from Agile; Scrum is one form of Agile. So in this video you don't see mention of a Scrum Master. Instead they talk about a Team Lead. However, the content on Definition of Done is relevant for OSE.

In this video he is discussing creating the Definition of Done at the Team level. The Product Owner needs to first supply the Team with an initial Definition of Done feature by feature. The Product Owner's Definition of Done revolves around the What (and explains the Why). The Team's Definition of Done defines the How.

One value of this video is that it stresses how all members of a multi-functional Team get involved in creating the Definition of Done. It is crucial that this Definition is agreed to by everyone on the Team. When the Team commits to the work included in a Release, and in each Sprint, they are doing so based on the agreed on Definition of Done for each Story.

There is quite a bit of excess jargon in this video, but have patience, and relate it to GVCS. For example, we not only need to have the machine design "done," but also CAD drawings, an instructional video, and many other instructional components. Unifying the release and "done-ness" of all of these is what seems like the best, and most radical!, contribution Scrum can make to GVCS. These underlying points of “What is Done?” are crucial for us to understand the work that is needed in Sprint Zero.

==OSE [[GVCS]] Scrum==

OSE already has many of the pieces necessary to Scrum. There has been a lot of thought put into how to maximize the value of the project, the resulting list of GVCS machines, and the step-by-step process needed make them. All the work that has already been done would be used as the ground work for a [[#Sprint ZERO]].

The main question seems to be, who would do the work of Sprint Zero for OSE. It seems that [[Marcin Jakubowski|Marcin]] needs to be centrally involved in the first three steps of Sprint Zero. In addition to Marcin for those first three steps, at minimum a Scrum Master would be needed. This is when the input Marcin brought back from TED in March (redistributing economic justice?) will be integrated into the current vision.

For the next two steps, turning the highest priority Epic into Stories, and prioritizing the Stories, another person(s) could step in for Marcin, if that seems best for OSE.

The need for Subject Matter Experts arises in the next step, creating the initial Definition of Done for each Story. An example of this would be creating standards for instructional videos, and ways to objectively measure if the instructional video for a certain machine meets those standards.

The real creative work needed to get ready for OSE Scrum involves understanding the incremental Releases, in other words, getting a vision of the order in which OSE "products" (the plans and documentation for each machine) will appear in the Product Backlog. The current list of [[GVCS Development Template#Process|31 steps]] needs to be reconfigured into Stories, and understood in terms of interim products that can be brought to the state of Done. The dependencies among the steps need to be charted out. This process will be used over and over, so getting it well understood, with really clear Definitions of Done, will help tremendously. The order in which the Stories from the 31 Steps appear will be a combination of the chronological dependencies of the steps, and the relative value of the Stories.

===Adapting Scrum to Hardware Technologies===

(Dear Reader: the ideas from the Maccherone blog are incompletely represented here. See the link in Notes for value perspective.)

Although there are likely more dependencies among Stories in hardware development, in Scrum you plan around these when planning a Release, and the Sprints within the Release.

In contrast to software development teams, hardware development teams may find that they need to consult technical specialists regularly to complete their work. The Scrum approach to this would involve seeing the specialists as outside suppliers. In general, however, the cross-functional training that occurs within the team, as people work in pairs, and as team members reach outside their comfort zone by selecting the Story with the highest priority, strengthens the team.<ref>Maccherone, Larry. [http://maccherone.com/larry/2010/02/23/top-10-questions-when-using-agile-on-hardware-projects/ Top 10 questions when using Agile on hardware projects]. 23 February 2010. Retrieved 1 March 2012.</ref>

==Notes==
<references />

==See Also==

* [http://www.scrumhw.org/ Scrum for Hardware Product Development] ''Bringing Scrum to the Hardware Product Development Community''
* [http://maccherone.com/larry/2010/02/23/top-10-questions-when-using-agile-on-hardware-projects/ Top 10 questions when using Agile on hardware projects]

[[Category:Project Management]]

Scrum

2012-03-06T02:08:33Z

Mia Van Meter: /* Adapting Scrum to Hardware Technologies */

Definition: '''[[wikipedia:Scrum (development)|Scrum]]''' is an iterative and incremental methodology for software projects and product- or application-development. It is also one of the variants of [[wikipedia:agile software development|agile software development]] methodologies.

==Why would a development team use Scrum?==

As demonstrated by high-powered software teams around the world, the Scrum process can increase a development team's efficiency dramatically. In recent years, some Scrum coaches (Scrum Masters) can consistently get development teams to be six times more efficient, and it is becoming almost unremarkable for a Scrum Master to kick a team into a productive state 15 times more productive than in their pre-Scrum days.

Scrum is essentially a double handful of rules for how a team should work together, and how they should be managed. Underneath those rules is a profound understanding of human nature. What motivates us? That is the essential question which Scrum answers. Scrum rules are designed to instill ownership, motivation, and creative problem-solving in team members. The dramatic results of a well-functioning Scrum team come from the synchronistic multiplying effect of a group of developers working “in the flow.” [http://en.wikipedia.org/wiki/Jeff_Sutherland/ Jeff Sutherland], one of the creators of Scrum, refers to these as “activated” teams.

Following [http://en.wikipedia.org/wiki/Lean_software_development/ Lean] development principles, the rules of Scrum are stripped down to the essentials. One of the implications of this is that teams must adopt all the Scrum rules in order to get Scrum results. Jeff Sutherland's favorite lecture topic seems to be “Scrumbutt.” This occurs when teams say, “Yes, we're doing Scrum, but...” and explain an aspect of Scrum they decided not to implement. According to Sutherland, you cannot get dramatic results unless you are pretty much a Scrum purist. That said, Scrum can “wrap around” other software development process technologies like, for example, XP or Lean. It's not essential to understand those technologies fully, for our purposes, but they are mentioned in the discussion on this page.

The most relevant question for a project like OSE is – is Scrum applicable outside the software development world? This is the answer that Joe Justice and the WikiSpeed team answer with a resounding “Yes!” In the 10-minute TEDX talk below, he explains briefly how the WikiSpeed Team, a collection of 44 volunteers in 4 countries, in three months used Scrum and associated processes to design and build a road-certifiable 4-person commuter car that can get over 100 miles per gallon in standard EPA road tests. The relevance of this to OSE is obvious – a distributed team of volunteers co-developing revolutionary hardware, sound familiar? It's well worth your while to spend a few hours absorbing the information on Scrum that this page points to, and to help explore its relevance for OSE in general, and the GVCS in particular.

In this video, Joe Justice, of WikiSpeed, explains the process his all-volunteer design team used to exceed expectations in their fuel-efficient car design.

<html><iframe width="300" height="182" src="http://www.youtube.com/watch?v=x8jdx-lf2Dw" frameborder="0" allowfullscreen></iframe></html>

.
.

.
.

==What is Scrum?==

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/watch?v=Q5k7a9YEoUI" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
The video above is a great first introduction to Scrum! It's fast paced, and the graphics easily convey the important information.

Of course, like any single Scrum coach, this one has his own take on Scrum, and in some instances it's likely that OSE Scrum will be different.

To review his core concepts:

Roles: Product Owner, Scrum Master, Team Members (developers, testers, customers)

Release Planning:
*Product Backlog– Estimate for each feature wanted in product.
*Release Backlog
*plan 4-12 Sprints – a substantive back log to a ship-ready state
*Sprint Backlog

Burndown Chart – day by day measure of the amount of work left in a Release, or Sprint

Bugs – have a separate Defect Backlog. Resolve bugs within the Sprint.

Daily Scrum – short, standing, identify bugs.

So that video is a great introduction to Scrum, but how would we actually get started?

The Scrum process starts with the Product Owner. They are responsible for creating the Product Backlog, creating the Development Team, and for providing the Team with the tools necessary for them to work. The Scrum Master helps the Product Owner with these tasks.

===Sprint ZERO===

To get ready for the first development Sprint, the Product Owner and the Scrum Master need to meet together, and with the Team, and do some initial preparation. The amount of time spent on Sprint Zero should be limited, and agreed upon in advance. Unfinished preparation can be added to the Product Backlog when Sprint Zero is finished. Additionally, the task of adding to the Product Backlog, and refining features that are down the road a bit, will be ongoing tasks for the Product Owner.

The most important outcome of Sprint Zero is to create understanding about the value of the work. Given that OSE might choose to have a team (Scrum) of Product Owners, it could make implementation more clear if the business values we are creating are explicitly ranked. Usually the process of identifying and clarifying the business value is held more distantly from the Team. In the case of OSE, it seems likely that a group of people will be determining the relative priorities of our business values, and the relative rankings of the features that we're planning on creating.

Here are some further questions to be taken up during Sprint Zero:
* Do we have the right people with the right skills? Is there a need for consultants, etc.?

* Given the Epic User Stories, the values, and the efinitions of done, what sort of work place, tools and technology set up are indicated?

* What is the general approach we are taking? What will be the length of our Sprints? What is the Road Map -- the key release points? How many teams will there be? If there are multiple teams, how will the Scrum Masters and the Product Owners from the multiple teams work together?

At the end of Sprint Zero, the Product Backlog must contain enough prioritized Stories to fill at least the first Release. Ideally, there would be enough Stories for two or three releases, so that the broad outlines of the technology and personnel needed can be understood.

Here's a possible outline for Sprint Zero:
Determine the length of sprints
Identify business value (the criteria to prioritize Stories)
Create epics. Prioritize epics (consider relative business value)
For the highest priority epic, turn the epic into stories
Prioritize the stories (consider relative business value)
For each story, create a definition of done
Create a team(s) workspace(s), and provide appropriate technology
Configure the team(s)

The following sections explain the Scrum terms needed to understand Sprint Zero work.

===User Stories===

We've been talking about ranking the features that make up the Product Backlog. In Scrum, these features are called Stories. There is an art to defining a Scrum Story, as you might imagine. Stories often take this form:

As _[User]_____, I want _[feature]_______, so that __[value]______.

An example:

* As a fabricator making a CNC Torch Table, I want complete and accurate CAD drawings, so that my efforts will result in a well-functioning machine.

Because the User is included in defining the feature, these are known as User Stories. The following video explains a good way to evaluate and improve User Stories, which are the list of features that make up the Product Backlog.

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=L_NyCczp0Fk&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.

To review the key ideas of the video:

'''Independent''' – dependencies among or between Stories need to be identified, eliminated, or tracked. An example of dependency: the training video for making a machine cannot be made until the machine is designed.
'''Negotiable''' – the Product Owner and the Team co-create the value and attributes of features (Stories)
'''Valuable''' – all Stories are connected directly to business value.
'''Estimable''' – the Team estimates the size of the Stories relative to each other.
'''Small''' – an important concept is raised here. Stories that are coming up in priority in the first or second Release should be small enough to be finished in one Sprint. Stories that are being implemented later can be large (Epics – more on this below).
'''Testable''' – knowing how we will know the Story is done, also called knowing the Definition of Done.

This review of the qualities of a good User Story gives some idea of the work to be done during Sprint Zero, while the User Stories are created, combined in one list, and then prioritized to make up the Product Backlog.

===Epic User Stories===

During Sprint Zero, the Product Owner will create a list of Epics. Epics are very large Stories. An example:
* As OSE, I want complete training materials in English for the 50 tools in GVCS on DVD, so that anyone with moderate experience in fabrication, and with access to the necessary tools and materials, can fabricate any of the 50 tools.

The list of Epics doesn't have to be exhaustive, but it should be thoroughly discussed and described, using the criteria for Stories developed in the video above.

===Definition of Done===

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=9FnZsaRujpw&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
NOTE -- this video is LOUD!

Review of the main concepts of the video:

This video is from Agile; Scrum is one form of Agile. So in this video you don't see mention of a Scrum Master. Instead they talk about a Team Lead. However, the content on Definition of Done is relevant for OSE.

In this video he is discussing creating the Definition of Done at the Team level. The Product Owner needs to first supply the Team with an initial Definition of Done feature by feature. The Product Owner's Definition of Done revolves around the What (and explains the Why). The Team's Definition of Done defines the How.

One value of this video is that it stresses how all members of a multi-functional Team get involved in creating the Definition of Done. It is crucial that this Definition is agreed to by everyone on the Team. When the Team commits to the work included in a Release, and in each Sprint, they are doing so based on the agreed on Definition of Done for each Story.

There is quite a bit of excess jargon in this video, but have patience, and relate it to GVCS. For example, we not only need to have the machine design "done," but also CAD drawings, an instructional video, and many other instructional components. Unifying the release and "done-ness" of all of these is what seems like the best, and most radical!, contribution Scrum can make to GVCS. These underlying points of “What is Done?” are crucial for us to understand the work that is needed in Sprint Zero.

==OSE [[GVCS]] Scrum==

OSE already has many of the pieces necessary to Scrum. There has been a lot of thought put into how to maximize the value of the project, the resulting list of GVCS machines, and the step-by-step process needed make them. All the work that has already been done would be used as the ground work for a [[#Sprint ZERO]].

The main question seems to be, who would do the work of Sprint Zero for OSE. It seems that [[Marcin Jakubowski|Marcin]] needs to be centrally involved in the first three steps of Sprint Zero. In addition to Marcin for those first three steps, at minimum a Scrum Master would be needed. This is when the input Marcin brought back from TED in March (redistributing economic justice?) will be integrated into the current vision.

For the next two steps, turning the highest priority Epic into Stories, and prioritizing the Stories, another person(s) could step in for Marcin, if that seems best for OSE.

The need for Subject Matter Experts arises in the next step, creating the initial Definition of Done for each Story. An example of this would be creating standards for instructional videos, and ways to objectively measure if the instructional video for a certain machine meets those standards.

The real creative work needed to get ready for OSE Scrum involves understanding the incremental Releases, in other words, getting a vision of the order in which OSE "products" (the plans and documentation for each machine) will appear in the Product Backlog. The current list of [[GVCS Development Template#Process|31 steps]] needs to be reconfigured into Stories, and understood in terms of interim products that can be brought to the state of Done. The dependencies among the steps need to be charted out. This process will be used over and over, so getting it well understood, with really clear Definitions of Done, will help tremendously. The order in which the Stories from the 31 Steps appear will be a combination of the chronological dependencies of the steps, and the relative value of the Stories.

===Adapting Scrum to Hardware Technologies===

The main difficulty

Although there are likely more dependencies among Stories in hardware development, in Scrum you plan around these when planning a Release, and the Sprints within the Release.

In contrast to software development teams, hardware development teams may find that they need to consult technical specialists regularly to complete their work. The Scrum approach to this would involve seeing the specialists as outside suppliers. In general, however, the cross-functional training that occurs within the team, as people work in pairs, and as team members reach outside their comfort zone by selecting the Story with the highest priority, strengthens the team.<ref>Maccherone, Larry. [http://maccherone.com/larry/2010/02/23/top-10-questions-when-using-agile-on-hardware-projects/ Top 10 questions when using Agile on hardware projects]. 23 February 2010. Retrieved 1 March 2012.</ref>

==Notes==
<references />

==See Also==

* [http://www.scrumhw.org/ Scrum for Hardware Product Development] ''Bringing Scrum to the Hardware Product Development Community''
* [http://maccherone.com/larry/2010/02/23/top-10-questions-when-using-agile-on-hardware-projects/ Top 10 questions when using Agile on hardware projects]

[[Category:Project Management]]

Scrum

2012-03-06T01:10:12Z

Mia Van Meter: /* Adapting Scrum to Hardware Technologies */

Definition: '''[[wikipedia:Scrum (development)|Scrum]]''' is an iterative and incremental methodology for software projects and product- or application-development. It is also one of the variants of [[wikipedia:agile software development|agile software development]] methodologies.

==Why would a development team use Scrum?==

As demonstrated by high-powered software teams around the world, the Scrum process can increase a development team's efficiency dramatically. In recent years, some Scrum coaches (Scrum Masters) can consistently get development teams to be six times more efficient, and it is becoming almost unremarkable for a Scrum Master to kick a team into a productive state 15 times more productive than in their pre-Scrum days.

Scrum is essentially a double handful of rules for how a team should work together, and how they should be managed. Underneath those rules is a profound understanding of human nature. What motivates us? That is the essential question which Scrum answers. Scrum rules are designed to instill ownership, motivation, and creative problem-solving in team members. The dramatic results of a well-functioning Scrum team come from the synchronistic multiplying effect of a group of developers working “in the flow.” [http://en.wikipedia.org/wiki/Jeff_Sutherland/ Jeff Sutherland], one of the creators of Scrum, refers to these as “activated” teams.

Following [http://en.wikipedia.org/wiki/Lean_software_development/ Lean] development principles, the rules of Scrum are stripped down to the essentials. One of the implications of this is that teams must adopt all the Scrum rules in order to get Scrum results. Jeff Sutherland's favorite lecture topic seems to be “Scrumbutt.” This occurs when teams say, “Yes, we're doing Scrum, but...” and explain an aspect of Scrum they decided not to implement. According to Sutherland, you cannot get dramatic results unless you are pretty much a Scrum purist. That said, Scrum can “wrap around” other software development process technologies like, for example, XP or Lean. It's not essential to understand those technologies fully, for our purposes, but they are mentioned in the discussion on this page.

The most relevant question for a project like OSE is – is Scrum applicable outside the software development world? This is the answer that Joe Justice and the WikiSpeed team answer with a resounding “Yes!” In the 10-minute TEDX talk below, he explains briefly how the WikiSpeed Team, a collection of 44 volunteers in 4 countries, in three months used Scrum and associated processes to design and build a road-certifiable 4-person commuter car that can get over 100 miles per gallon in standard EPA road tests. The relevance of this to OSE is obvious – a distributed team of volunteers co-developing revolutionary hardware, sound familiar? It's well worth your while to spend a few hours absorbing the information on Scrum that this page points to, and to help explore its relevance for OSE in general, and the GVCS in particular.

In this video, Joe Justice, of WikiSpeed, explains the process his all-volunteer design team used to exceed expectations in their fuel-efficient car design.

<html><iframe width="300" height="182" src="http://www.youtube.com/watch?v=x8jdx-lf2Dw" frameborder="0" allowfullscreen></iframe></html>

.
.

.
.

==What is Scrum?==

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/watch?v=Q5k7a9YEoUI" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
The video above is a great first introduction to Scrum! It's fast paced, and the graphics easily convey the important information.

Of course, like any single Scrum coach, this one has his own take on Scrum, and in some instances it's likely that OSE Scrum will be different.

To review his core concepts:

Roles: Product Owner, Scrum Master, Team Members (developers, testers, customers)

Release Planning:
*Product Backlog– Estimate for each feature wanted in product.
*Release Backlog
*plan 4-12 Sprints – a substantive back log to a ship-ready state
*Sprint Backlog

Burndown Chart – day by day measure of the amount of work left in a Release, or Sprint

Bugs – have a separate Defect Backlog. Resolve bugs within the Sprint.

Daily Scrum – short, standing, identify bugs.

So that video is a great introduction to Scrum, but how would we actually get started?

The Scrum process starts with the Product Owner. They are responsible for creating the Product Backlog, creating the Development Team, and for providing the Team with the tools necessary for them to work. The Scrum Master helps the Product Owner with these tasks.

===Sprint ZERO===

To get ready for the first development Sprint, the Product Owner and the Scrum Master need to meet together, and with the Team, and do some initial preparation. The amount of time spent on Sprint Zero should be limited, and agreed upon in advance. Unfinished preparation can be added to the Product Backlog when Sprint Zero is finished. Additionally, the task of adding to the Product Backlog, and refining features that are down the road a bit, will be ongoing tasks for the Product Owner.

The most important outcome of Sprint Zero is to create understanding about the value of the work. Given that OSE might choose to have a team (Scrum) of Product Owners, it could make implementation more clear if the business values we are creating are explicitly ranked. Usually the process of identifying and clarifying the business value is held more distantly from the Team. In the case of OSE, it seems likely that a group of people will be determining the relative priorities of our business values, and the relative rankings of the features that we're planning on creating.

Here are some further questions to be taken up during Sprint Zero:
* Do we have the right people with the right skills? Is there a need for consultants, etc.?

* Given the Epic User Stories, the values, and the efinitions of done, what sort of work place, tools and technology set up are indicated?

* What is the general approach we are taking? What will be the length of our Sprints? What is the Road Map -- the key release points? How many teams will there be? If there are multiple teams, how will the Scrum Masters and the Product Owners from the multiple teams work together?

At the end of Sprint Zero, the Product Backlog must contain enough prioritized Stories to fill at least the first Release. Ideally, there would be enough Stories for two or three releases, so that the broad outlines of the technology and personnel needed can be understood.

Here's a possible outline for Sprint Zero:
Determine the length of sprints
Identify business value (the criteria to prioritize Stories)
Create epics. Prioritize epics (consider relative business value)
For the highest priority epic, turn the epic into stories
Prioritize the stories (consider relative business value)
For each story, create a definition of done
Create a team(s) workspace(s), and provide appropriate technology
Configure the team(s)

The following sections explain the Scrum terms needed to understand Sprint Zero work.

===User Stories===

We've been talking about ranking the features that make up the Product Backlog. In Scrum, these features are called Stories. There is an art to defining a Scrum Story, as you might imagine. Stories often take this form:

As _[User]_____, I want _[feature]_______, so that __[value]______.

An example:

* As a fabricator making a CNC Torch Table, I want complete and accurate CAD drawings, so that my efforts will result in a well-functioning machine.

Because the User is included in defining the feature, these are known as User Stories. The following video explains a good way to evaluate and improve User Stories, which are the list of features that make up the Product Backlog.

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=L_NyCczp0Fk&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.

To review the key ideas of the video:

'''Independent''' – dependencies among or between Stories need to be identified, eliminated, or tracked. An example of dependency: the training video for making a machine cannot be made until the machine is designed.
'''Negotiable''' – the Product Owner and the Team co-create the value and attributes of features (Stories)
'''Valuable''' – all Stories are connected directly to business value.
'''Estimable''' – the Team estimates the size of the Stories relative to each other.
'''Small''' – an important concept is raised here. Stories that are coming up in priority in the first or second Release should be small enough to be finished in one Sprint. Stories that are being implemented later can be large (Epics – more on this below).
'''Testable''' – knowing how we will know the Story is done, also called knowing the Definition of Done.

This review of the qualities of a good User Story gives some idea of the work to be done during Sprint Zero, while the User Stories are created, combined in one list, and then prioritized to make up the Product Backlog.

===Epic User Stories===

During Sprint Zero, the Product Owner will create a list of Epics. Epics are very large Stories. An example:
* As OSE, I want complete training materials in English for the 50 tools in GVCS on DVD, so that anyone with moderate experience in fabrication, and with access to the necessary tools and materials, can fabricate any of the 50 tools.

The list of Epics doesn't have to be exhaustive, but it should be thoroughly discussed and described, using the criteria for Stories developed in the video above.

===Definition of Done===

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=9FnZsaRujpw&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
NOTE -- this video is LOUD!

Review of the main concepts of the video:

This video is from Agile; Scrum is one form of Agile. So in this video you don't see mention of a Scrum Master. Instead they talk about a Team Lead. However, the content on Definition of Done is relevant for OSE.

In this video he is discussing creating the Definition of Done at the Team level. The Product Owner needs to first supply the Team with an initial Definition of Done feature by feature. The Product Owner's Definition of Done revolves around the What (and explains the Why). The Team's Definition of Done defines the How.

One value of this video is that it stresses how all members of a multi-functional Team get involved in creating the Definition of Done. It is crucial that this Definition is agreed to by everyone on the Team. When the Team commits to the work included in a Release, and in each Sprint, they are doing so based on the agreed on Definition of Done for each Story.

There is quite a bit of excess jargon in this video, but have patience, and relate it to GVCS. For example, we not only need to have the machine design "done," but also CAD drawings, an instructional video, and many other instructional components. Unifying the release and "done-ness" of all of these is what seems like the best, and most radical!, contribution Scrum can make to GVCS. These underlying points of “What is Done?” are crucial for us to understand the work that is needed in Sprint Zero.

==OSE [[GVCS]] Scrum==

OSE already has many of the pieces necessary to Scrum. There has been a lot of thought put into how to maximize the value of the project, the resulting list of GVCS machines, and the step-by-step process needed make them. All the work that has already been done would be used as the ground work for a [[#Sprint ZERO]].

The main question seems to be, who would do the work of Sprint Zero for OSE. It seems that [[Marcin Jakubowski|Marcin]] needs to be centrally involved in the first three steps of Sprint Zero. In addition to Marcin for those first three steps, at minimum a Scrum Master would be needed. This is when the input Marcin brought back from TED in March (redistributing economic justice?) will be integrated into the current vision.

For the next two steps, turning the highest priority Epic into Stories, and prioritizing the Stories, another person(s) could step in for Marcin, if that seems best for OSE.

The need for Subject Matter Experts arises in the next step, creating the initial Definition of Done for each Story. An example of this would be creating standards for instructional videos, and ways to objectively measure if the instructional video for a certain machine meets those standards.

The real creative work needed to get ready for OSE Scrum involves understanding the incremental Releases, in other words, getting a vision of the order in which OSE "products" (the plans and documentation for each machine) will appear in the Product Backlog. The current list of [[GVCS Development Template#Process|31 steps]] needs to be reconfigured into Stories, and understood in terms of interim products that can be brought to the state of Done. The dependencies among the steps need to be charted out. This process will be used over and over, so getting it well understood, with really clear Definitions of Done, will help tremendously. The order in which the Stories from the 31 Steps appear will be a combination of the chronological dependencies of the steps, and the relative value of the Stories.

==Adapting Scrum to Hardware Technologies==

These comments come from a blog post.<ref>Maccherone, Larry. [http://maccherone.com/larry/2010/02/23/top-10-questions-when-using-agile-on-hardware-projects/ Top 10 questions when using Agile on hardware projects]. 23 February 2010. Retrieved 1 March 2012.</ref>

==Notes==
<references />

==See Also==

* [http://www.scrumhw.org/ Scrum for Hardware Product Development] ''Bringing Scrum to the Hardware Product Development Community''
* [http://maccherone.com/larry/2010/02/23/top-10-questions-when-using-agile-on-hardware-projects/ Top 10 questions when using Agile on hardware projects]

[[Category:Project Management]]

Scrum

2012-03-06T01:09:24Z

Mia Van Meter: /* Adapting Scrum to Hardware Technologies */

Definition: '''[[wikipedia:Scrum (development)|Scrum]]''' is an iterative and incremental methodology for software projects and product- or application-development. It is also one of the variants of [[wikipedia:agile software development|agile software development]] methodologies.

==Why would a development team use Scrum?==

As demonstrated by high-powered software teams around the world, the Scrum process can increase a development team's efficiency dramatically. In recent years, some Scrum coaches (Scrum Masters) can consistently get development teams to be six times more efficient, and it is becoming almost unremarkable for a Scrum Master to kick a team into a productive state 15 times more productive than in their pre-Scrum days.

Scrum is essentially a double handful of rules for how a team should work together, and how they should be managed. Underneath those rules is a profound understanding of human nature. What motivates us? That is the essential question which Scrum answers. Scrum rules are designed to instill ownership, motivation, and creative problem-solving in team members. The dramatic results of a well-functioning Scrum team come from the synchronistic multiplying effect of a group of developers working “in the flow.” [http://en.wikipedia.org/wiki/Jeff_Sutherland/ Jeff Sutherland], one of the creators of Scrum, refers to these as “activated” teams.

Following [http://en.wikipedia.org/wiki/Lean_software_development/ Lean] development principles, the rules of Scrum are stripped down to the essentials. One of the implications of this is that teams must adopt all the Scrum rules in order to get Scrum results. Jeff Sutherland's favorite lecture topic seems to be “Scrumbutt.” This occurs when teams say, “Yes, we're doing Scrum, but...” and explain an aspect of Scrum they decided not to implement. According to Sutherland, you cannot get dramatic results unless you are pretty much a Scrum purist. That said, Scrum can “wrap around” other software development process technologies like, for example, XP or Lean. It's not essential to understand those technologies fully, for our purposes, but they are mentioned in the discussion on this page.

The most relevant question for a project like OSE is – is Scrum applicable outside the software development world? This is the answer that Joe Justice and the WikiSpeed team answer with a resounding “Yes!” In the 10-minute TEDX talk below, he explains briefly how the WikiSpeed Team, a collection of 44 volunteers in 4 countries, in three months used Scrum and associated processes to design and build a road-certifiable 4-person commuter car that can get over 100 miles per gallon in standard EPA road tests. The relevance of this to OSE is obvious – a distributed team of volunteers co-developing revolutionary hardware, sound familiar? It's well worth your while to spend a few hours absorbing the information on Scrum that this page points to, and to help explore its relevance for OSE in general, and the GVCS in particular.

In this video, Joe Justice, of WikiSpeed, explains the process his all-volunteer design team used to exceed expectations in their fuel-efficient car design.

<html><iframe width="300" height="182" src="http://www.youtube.com/watch?v=x8jdx-lf2Dw" frameborder="0" allowfullscreen></iframe></html>

.
.

.
.

==What is Scrum?==

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/watch?v=Q5k7a9YEoUI" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
The video above is a great first introduction to Scrum! It's fast paced, and the graphics easily convey the important information.

Of course, like any single Scrum coach, this one has his own take on Scrum, and in some instances it's likely that OSE Scrum will be different.

To review his core concepts:

Roles: Product Owner, Scrum Master, Team Members (developers, testers, customers)

Release Planning:
*Product Backlog– Estimate for each feature wanted in product.
*Release Backlog
*plan 4-12 Sprints – a substantive back log to a ship-ready state
*Sprint Backlog

Burndown Chart – day by day measure of the amount of work left in a Release, or Sprint

Bugs – have a separate Defect Backlog. Resolve bugs within the Sprint.

Daily Scrum – short, standing, identify bugs.

So that video is a great introduction to Scrum, but how would we actually get started?

The Scrum process starts with the Product Owner. They are responsible for creating the Product Backlog, creating the Development Team, and for providing the Team with the tools necessary for them to work. The Scrum Master helps the Product Owner with these tasks.

===Sprint ZERO===

To get ready for the first development Sprint, the Product Owner and the Scrum Master need to meet together, and with the Team, and do some initial preparation. The amount of time spent on Sprint Zero should be limited, and agreed upon in advance. Unfinished preparation can be added to the Product Backlog when Sprint Zero is finished. Additionally, the task of adding to the Product Backlog, and refining features that are down the road a bit, will be ongoing tasks for the Product Owner.

The most important outcome of Sprint Zero is to create understanding about the value of the work. Given that OSE might choose to have a team (Scrum) of Product Owners, it could make implementation more clear if the business values we are creating are explicitly ranked. Usually the process of identifying and clarifying the business value is held more distantly from the Team. In the case of OSE, it seems likely that a group of people will be determining the relative priorities of our business values, and the relative rankings of the features that we're planning on creating.

Here are some further questions to be taken up during Sprint Zero:
* Do we have the right people with the right skills? Is there a need for consultants, etc.?

* Given the Epic User Stories, the values, and the efinitions of done, what sort of work place, tools and technology set up are indicated?

* What is the general approach we are taking? What will be the length of our Sprints? What is the Road Map -- the key release points? How many teams will there be? If there are multiple teams, how will the Scrum Masters and the Product Owners from the multiple teams work together?

At the end of Sprint Zero, the Product Backlog must contain enough prioritized Stories to fill at least the first Release. Ideally, there would be enough Stories for two or three releases, so that the broad outlines of the technology and personnel needed can be understood.

Here's a possible outline for Sprint Zero:
Determine the length of sprints
Identify business value (the criteria to prioritize Stories)
Create epics. Prioritize epics (consider relative business value)
For the highest priority epic, turn the epic into stories
Prioritize the stories (consider relative business value)
For each story, create a definition of done
Create a team(s) workspace(s), and provide appropriate technology
Configure the team(s)

The following sections explain the Scrum terms needed to understand Sprint Zero work.

===User Stories===

We've been talking about ranking the features that make up the Product Backlog. In Scrum, these features are called Stories. There is an art to defining a Scrum Story, as you might imagine. Stories often take this form:

As _[User]_____, I want _[feature]_______, so that __[value]______.

An example:

* As a fabricator making a CNC Torch Table, I want complete and accurate CAD drawings, so that my efforts will result in a well-functioning machine.

Because the User is included in defining the feature, these are known as User Stories. The following video explains a good way to evaluate and improve User Stories, which are the list of features that make up the Product Backlog.

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=L_NyCczp0Fk&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.

To review the key ideas of the video:

'''Independent''' – dependencies among or between Stories need to be identified, eliminated, or tracked. An example of dependency: the training video for making a machine cannot be made until the machine is designed.
'''Negotiable''' – the Product Owner and the Team co-create the value and attributes of features (Stories)
'''Valuable''' – all Stories are connected directly to business value.
'''Estimable''' – the Team estimates the size of the Stories relative to each other.
'''Small''' – an important concept is raised here. Stories that are coming up in priority in the first or second Release should be small enough to be finished in one Sprint. Stories that are being implemented later can be large (Epics – more on this below).
'''Testable''' – knowing how we will know the Story is done, also called knowing the Definition of Done.

This review of the qualities of a good User Story gives some idea of the work to be done during Sprint Zero, while the User Stories are created, combined in one list, and then prioritized to make up the Product Backlog.

===Epic User Stories===

During Sprint Zero, the Product Owner will create a list of Epics. Epics are very large Stories. An example:
* As OSE, I want complete training materials in English for the 50 tools in GVCS on DVD, so that anyone with moderate experience in fabrication, and with access to the necessary tools and materials, can fabricate any of the 50 tools.

The list of Epics doesn't have to be exhaustive, but it should be thoroughly discussed and described, using the criteria for Stories developed in the video above.

===Definition of Done===

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=9FnZsaRujpw&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
NOTE -- this video is LOUD!

Review of the main concepts of the video:

This video is from Agile; Scrum is one form of Agile. So in this video you don't see mention of a Scrum Master. Instead they talk about a Team Lead. However, the content on Definition of Done is relevant for OSE.

In this video he is discussing creating the Definition of Done at the Team level. The Product Owner needs to first supply the Team with an initial Definition of Done feature by feature. The Product Owner's Definition of Done revolves around the What (and explains the Why). The Team's Definition of Done defines the How.

One value of this video is that it stresses how all members of a multi-functional Team get involved in creating the Definition of Done. It is crucial that this Definition is agreed to by everyone on the Team. When the Team commits to the work included in a Release, and in each Sprint, they are doing so based on the agreed on Definition of Done for each Story.

There is quite a bit of excess jargon in this video, but have patience, and relate it to GVCS. For example, we not only need to have the machine design "done," but also CAD drawings, an instructional video, and many other instructional components. Unifying the release and "done-ness" of all of these is what seems like the best, and most radical!, contribution Scrum can make to GVCS. These underlying points of “What is Done?” are crucial for us to understand the work that is needed in Sprint Zero.

==OSE [[GVCS]] Scrum==

OSE already has many of the pieces necessary to Scrum. There has been a lot of thought put into how to maximize the value of the project, the resulting list of GVCS machines, and the step-by-step process needed make them. All the work that has already been done would be used as the ground work for a [[#Sprint ZERO]].

The main question seems to be, who would do the work of Sprint Zero for OSE. It seems that [[Marcin Jakubowski|Marcin]] needs to be centrally involved in the first three steps of Sprint Zero. In addition to Marcin for those first three steps, at minimum a Scrum Master would be needed. This is when the input Marcin brought back from TED in March (redistributing economic justice?) will be integrated into the current vision.

For the next two steps, turning the highest priority Epic into Stories, and prioritizing the Stories, another person(s) could step in for Marcin, if that seems best for OSE.

The need for Subject Matter Experts arises in the next step, creating the initial Definition of Done for each Story. An example of this would be creating standards for instructional videos, and ways to objectively measure if the instructional video for a certain machine meets those standards.

The real creative work needed to get ready for OSE Scrum involves understanding the incremental Releases, in other words, getting a vision of the order in which OSE "products" (the plans and documentation for each machine) will appear in the Product Backlog. The current list of [[GVCS Development Template#Process|31 steps]] needs to be reconfigured into Stories, and understood in terms of interim products that can be brought to the state of Done. The dependencies among the steps need to be charted out. This process will be used over and over, so getting it well understood, with really clear Definitions of Done, will help tremendously. The order in which the Stories from the 31 Steps appear will be a combination of the chronological dependencies of the steps, and the relative value of the Stories.

==Adapting Scrum to Hardware Technologies==

These comments come from a blog post.<ref>{{Maccherone, Larry. [http://maccherone.com/larry/2010/02/23/top-10-questions-when-using-agile-on-hardware-projects/ Top 10 questions when using Agile on hardware projects]. 23 February 2010. Retrieved 1 March 2012.}}</ref>

==Notes==
<references />

==See Also==

* [http://www.scrumhw.org/ Scrum for Hardware Product Development] ''Bringing Scrum to the Hardware Product Development Community''
* [http://maccherone.com/larry/2010/02/23/top-10-questions-when-using-agile-on-hardware-projects/ Top 10 questions when using Agile on hardware projects]

[[Category:Project Management]]

Scrum

2012-03-06T01:05:52Z

Mia Van Meter: /* Adapting Scrum to Hardware Technologies */

Definition: '''[[wikipedia:Scrum (development)|Scrum]]''' is an iterative and incremental methodology for software projects and product- or application-development. It is also one of the variants of [[wikipedia:agile software development|agile software development]] methodologies.

==Why would a development team use Scrum?==

As demonstrated by high-powered software teams around the world, the Scrum process can increase a development team's efficiency dramatically. In recent years, some Scrum coaches (Scrum Masters) can consistently get development teams to be six times more efficient, and it is becoming almost unremarkable for a Scrum Master to kick a team into a productive state 15 times more productive than in their pre-Scrum days.

Scrum is essentially a double handful of rules for how a team should work together, and how they should be managed. Underneath those rules is a profound understanding of human nature. What motivates us? That is the essential question which Scrum answers. Scrum rules are designed to instill ownership, motivation, and creative problem-solving in team members. The dramatic results of a well-functioning Scrum team come from the synchronistic multiplying effect of a group of developers working “in the flow.” [http://en.wikipedia.org/wiki/Jeff_Sutherland/ Jeff Sutherland], one of the creators of Scrum, refers to these as “activated” teams.

Following [http://en.wikipedia.org/wiki/Lean_software_development/ Lean] development principles, the rules of Scrum are stripped down to the essentials. One of the implications of this is that teams must adopt all the Scrum rules in order to get Scrum results. Jeff Sutherland's favorite lecture topic seems to be “Scrumbutt.” This occurs when teams say, “Yes, we're doing Scrum, but...” and explain an aspect of Scrum they decided not to implement. According to Sutherland, you cannot get dramatic results unless you are pretty much a Scrum purist. That said, Scrum can “wrap around” other software development process technologies like, for example, XP or Lean. It's not essential to understand those technologies fully, for our purposes, but they are mentioned in the discussion on this page.

The most relevant question for a project like OSE is – is Scrum applicable outside the software development world? This is the answer that Joe Justice and the WikiSpeed team answer with a resounding “Yes!” In the 10-minute TEDX talk below, he explains briefly how the WikiSpeed Team, a collection of 44 volunteers in 4 countries, in three months used Scrum and associated processes to design and build a road-certifiable 4-person commuter car that can get over 100 miles per gallon in standard EPA road tests. The relevance of this to OSE is obvious – a distributed team of volunteers co-developing revolutionary hardware, sound familiar? It's well worth your while to spend a few hours absorbing the information on Scrum that this page points to, and to help explore its relevance for OSE in general, and the GVCS in particular.

In this video, Joe Justice, of WikiSpeed, explains the process his all-volunteer design team used to exceed expectations in their fuel-efficient car design.

<html><iframe width="300" height="182" src="http://www.youtube.com/watch?v=x8jdx-lf2Dw" frameborder="0" allowfullscreen></iframe></html>

.
.

.
.

==What is Scrum?==

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/watch?v=Q5k7a9YEoUI" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
The video above is a great first introduction to Scrum! It's fast paced, and the graphics easily convey the important information.

Of course, like any single Scrum coach, this one has his own take on Scrum, and in some instances it's likely that OSE Scrum will be different.

To review his core concepts:

Roles: Product Owner, Scrum Master, Team Members (developers, testers, customers)

Release Planning:
*Product Backlog– Estimate for each feature wanted in product.
*Release Backlog
*plan 4-12 Sprints – a substantive back log to a ship-ready state
*Sprint Backlog

Burndown Chart – day by day measure of the amount of work left in a Release, or Sprint

Bugs – have a separate Defect Backlog. Resolve bugs within the Sprint.

Daily Scrum – short, standing, identify bugs.

So that video is a great introduction to Scrum, but how would we actually get started?

The Scrum process starts with the Product Owner. They are responsible for creating the Product Backlog, creating the Development Team, and for providing the Team with the tools necessary for them to work. The Scrum Master helps the Product Owner with these tasks.

===Sprint ZERO===

To get ready for the first development Sprint, the Product Owner and the Scrum Master need to meet together, and with the Team, and do some initial preparation. The amount of time spent on Sprint Zero should be limited, and agreed upon in advance. Unfinished preparation can be added to the Product Backlog when Sprint Zero is finished. Additionally, the task of adding to the Product Backlog, and refining features that are down the road a bit, will be ongoing tasks for the Product Owner.

The most important outcome of Sprint Zero is to create understanding about the value of the work. Given that OSE might choose to have a team (Scrum) of Product Owners, it could make implementation more clear if the business values we are creating are explicitly ranked. Usually the process of identifying and clarifying the business value is held more distantly from the Team. In the case of OSE, it seems likely that a group of people will be determining the relative priorities of our business values, and the relative rankings of the features that we're planning on creating.

Here are some further questions to be taken up during Sprint Zero:
* Do we have the right people with the right skills? Is there a need for consultants, etc.?

* Given the Epic User Stories, the values, and the efinitions of done, what sort of work place, tools and technology set up are indicated?

* What is the general approach we are taking? What will be the length of our Sprints? What is the Road Map -- the key release points? How many teams will there be? If there are multiple teams, how will the Scrum Masters and the Product Owners from the multiple teams work together?

At the end of Sprint Zero, the Product Backlog must contain enough prioritized Stories to fill at least the first Release. Ideally, there would be enough Stories for two or three releases, so that the broad outlines of the technology and personnel needed can be understood.

Here's a possible outline for Sprint Zero:
Determine the length of sprints
Identify business value (the criteria to prioritize Stories)
Create epics. Prioritize epics (consider relative business value)
For the highest priority epic, turn the epic into stories
Prioritize the stories (consider relative business value)
For each story, create a definition of done
Create a team(s) workspace(s), and provide appropriate technology
Configure the team(s)

The following sections explain the Scrum terms needed to understand Sprint Zero work.

===User Stories===

We've been talking about ranking the features that make up the Product Backlog. In Scrum, these features are called Stories. There is an art to defining a Scrum Story, as you might imagine. Stories often take this form:

As _[User]_____, I want _[feature]_______, so that __[value]______.

An example:

* As a fabricator making a CNC Torch Table, I want complete and accurate CAD drawings, so that my efforts will result in a well-functioning machine.

Because the User is included in defining the feature, these are known as User Stories. The following video explains a good way to evaluate and improve User Stories, which are the list of features that make up the Product Backlog.

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=L_NyCczp0Fk&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.

To review the key ideas of the video:

'''Independent''' – dependencies among or between Stories need to be identified, eliminated, or tracked. An example of dependency: the training video for making a machine cannot be made until the machine is designed.
'''Negotiable''' – the Product Owner and the Team co-create the value and attributes of features (Stories)
'''Valuable''' – all Stories are connected directly to business value.
'''Estimable''' – the Team estimates the size of the Stories relative to each other.
'''Small''' – an important concept is raised here. Stories that are coming up in priority in the first or second Release should be small enough to be finished in one Sprint. Stories that are being implemented later can be large (Epics – more on this below).
'''Testable''' – knowing how we will know the Story is done, also called knowing the Definition of Done.

This review of the qualities of a good User Story gives some idea of the work to be done during Sprint Zero, while the User Stories are created, combined in one list, and then prioritized to make up the Product Backlog.

===Epic User Stories===

During Sprint Zero, the Product Owner will create a list of Epics. Epics are very large Stories. An example:
* As OSE, I want complete training materials in English for the 50 tools in GVCS on DVD, so that anyone with moderate experience in fabrication, and with access to the necessary tools and materials, can fabricate any of the 50 tools.

The list of Epics doesn't have to be exhaustive, but it should be thoroughly discussed and described, using the criteria for Stories developed in the video above.

===Definition of Done===

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=9FnZsaRujpw&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
NOTE -- this video is LOUD!

Review of the main concepts of the video:

This video is from Agile; Scrum is one form of Agile. So in this video you don't see mention of a Scrum Master. Instead they talk about a Team Lead. However, the content on Definition of Done is relevant for OSE.

In this video he is discussing creating the Definition of Done at the Team level. The Product Owner needs to first supply the Team with an initial Definition of Done feature by feature. The Product Owner's Definition of Done revolves around the What (and explains the Why). The Team's Definition of Done defines the How.

One value of this video is that it stresses how all members of a multi-functional Team get involved in creating the Definition of Done. It is crucial that this Definition is agreed to by everyone on the Team. When the Team commits to the work included in a Release, and in each Sprint, they are doing so based on the agreed on Definition of Done for each Story.

There is quite a bit of excess jargon in this video, but have patience, and relate it to GVCS. For example, we not only need to have the machine design "done," but also CAD drawings, an instructional video, and many other instructional components. Unifying the release and "done-ness" of all of these is what seems like the best, and most radical!, contribution Scrum can make to GVCS. These underlying points of “What is Done?” are crucial for us to understand the work that is needed in Sprint Zero.

==OSE [[GVCS]] Scrum==

OSE already has many of the pieces necessary to Scrum. There has been a lot of thought put into how to maximize the value of the project, the resulting list of GVCS machines, and the step-by-step process needed make them. All the work that has already been done would be used as the ground work for a [[#Sprint ZERO]].

The main question seems to be, who would do the work of Sprint Zero for OSE. It seems that [[Marcin Jakubowski|Marcin]] needs to be centrally involved in the first three steps of Sprint Zero. In addition to Marcin for those first three steps, at minimum a Scrum Master would be needed. This is when the input Marcin brought back from TED in March (redistributing economic justice?) will be integrated into the current vision.

For the next two steps, turning the highest priority Epic into Stories, and prioritizing the Stories, another person(s) could step in for Marcin, if that seems best for OSE.

The need for Subject Matter Experts arises in the next step, creating the initial Definition of Done for each Story. An example of this would be creating standards for instructional videos, and ways to objectively measure if the instructional video for a certain machine meets those standards.

The real creative work needed to get ready for OSE Scrum involves understanding the incremental Releases, in other words, getting a vision of the order in which OSE "products" (the plans and documentation for each machine) will appear in the Product Backlog. The current list of [[GVCS Development Template#Process|31 steps]] needs to be reconfigured into Stories, and understood in terms of interim products that can be brought to the state of Done. The dependencies among the steps need to be charted out. This process will be used over and over, so getting it well understood, with really clear Definitions of Done, will help tremendously. The order in which the Stories from the 31 Steps appear will be a combination of the chronological dependencies of the steps, and the relative value of the Stories.

==Adapting Scrum to Hardware Technologies==

These comments come from a blog post.<ref>{{
| last = Maccherone
| first = Larry
| title = Top 10 questions when using Agile on hardware projects
| date = February 23, 2010
| url = http://maccherone.com/larry/2010/02/23/top-10-questions-when-using-agile-on-hardware-projects/
| format = blog
| doi =
| accessdate = March 1, 2012}}</ref>

==Notes==
<references />

==See Also==

* [http://www.scrumhw.org/ Scrum for Hardware Product Development] ''Bringing Scrum to the Hardware Product Development Community''
* [http://maccherone.com/larry/2010/02/23/top-10-questions-when-using-agile-on-hardware-projects/ Top 10 questions when using Agile on hardware projects]

[[Category:Project Management]]

Scrum

2012-03-06T01:05:16Z

Mia Van Meter: /* Notes */

Definition: '''[[wikipedia:Scrum (development)|Scrum]]''' is an iterative and incremental methodology for software projects and product- or application-development. It is also one of the variants of [[wikipedia:agile software development|agile software development]] methodologies.

==Why would a development team use Scrum?==

As demonstrated by high-powered software teams around the world, the Scrum process can increase a development team's efficiency dramatically. In recent years, some Scrum coaches (Scrum Masters) can consistently get development teams to be six times more efficient, and it is becoming almost unremarkable for a Scrum Master to kick a team into a productive state 15 times more productive than in their pre-Scrum days.

Scrum is essentially a double handful of rules for how a team should work together, and how they should be managed. Underneath those rules is a profound understanding of human nature. What motivates us? That is the essential question which Scrum answers. Scrum rules are designed to instill ownership, motivation, and creative problem-solving in team members. The dramatic results of a well-functioning Scrum team come from the synchronistic multiplying effect of a group of developers working “in the flow.” [http://en.wikipedia.org/wiki/Jeff_Sutherland/ Jeff Sutherland], one of the creators of Scrum, refers to these as “activated” teams.

Following [http://en.wikipedia.org/wiki/Lean_software_development/ Lean] development principles, the rules of Scrum are stripped down to the essentials. One of the implications of this is that teams must adopt all the Scrum rules in order to get Scrum results. Jeff Sutherland's favorite lecture topic seems to be “Scrumbutt.” This occurs when teams say, “Yes, we're doing Scrum, but...” and explain an aspect of Scrum they decided not to implement. According to Sutherland, you cannot get dramatic results unless you are pretty much a Scrum purist. That said, Scrum can “wrap around” other software development process technologies like, for example, XP or Lean. It's not essential to understand those technologies fully, for our purposes, but they are mentioned in the discussion on this page.

The most relevant question for a project like OSE is – is Scrum applicable outside the software development world? This is the answer that Joe Justice and the WikiSpeed team answer with a resounding “Yes!” In the 10-minute TEDX talk below, he explains briefly how the WikiSpeed Team, a collection of 44 volunteers in 4 countries, in three months used Scrum and associated processes to design and build a road-certifiable 4-person commuter car that can get over 100 miles per gallon in standard EPA road tests. The relevance of this to OSE is obvious – a distributed team of volunteers co-developing revolutionary hardware, sound familiar? It's well worth your while to spend a few hours absorbing the information on Scrum that this page points to, and to help explore its relevance for OSE in general, and the GVCS in particular.

In this video, Joe Justice, of WikiSpeed, explains the process his all-volunteer design team used to exceed expectations in their fuel-efficient car design.

<html><iframe width="300" height="182" src="http://www.youtube.com/watch?v=x8jdx-lf2Dw" frameborder="0" allowfullscreen></iframe></html>

.
.

.
.

==What is Scrum?==

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/watch?v=Q5k7a9YEoUI" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
The video above is a great first introduction to Scrum! It's fast paced, and the graphics easily convey the important information.

Of course, like any single Scrum coach, this one has his own take on Scrum, and in some instances it's likely that OSE Scrum will be different.

To review his core concepts:

Roles: Product Owner, Scrum Master, Team Members (developers, testers, customers)

Release Planning:
*Product Backlog– Estimate for each feature wanted in product.
*Release Backlog
*plan 4-12 Sprints – a substantive back log to a ship-ready state
*Sprint Backlog

Burndown Chart – day by day measure of the amount of work left in a Release, or Sprint

Bugs – have a separate Defect Backlog. Resolve bugs within the Sprint.

Daily Scrum – short, standing, identify bugs.

So that video is a great introduction to Scrum, but how would we actually get started?

The Scrum process starts with the Product Owner. They are responsible for creating the Product Backlog, creating the Development Team, and for providing the Team with the tools necessary for them to work. The Scrum Master helps the Product Owner with these tasks.

===Sprint ZERO===

To get ready for the first development Sprint, the Product Owner and the Scrum Master need to meet together, and with the Team, and do some initial preparation. The amount of time spent on Sprint Zero should be limited, and agreed upon in advance. Unfinished preparation can be added to the Product Backlog when Sprint Zero is finished. Additionally, the task of adding to the Product Backlog, and refining features that are down the road a bit, will be ongoing tasks for the Product Owner.

The most important outcome of Sprint Zero is to create understanding about the value of the work. Given that OSE might choose to have a team (Scrum) of Product Owners, it could make implementation more clear if the business values we are creating are explicitly ranked. Usually the process of identifying and clarifying the business value is held more distantly from the Team. In the case of OSE, it seems likely that a group of people will be determining the relative priorities of our business values, and the relative rankings of the features that we're planning on creating.

Here are some further questions to be taken up during Sprint Zero:
* Do we have the right people with the right skills? Is there a need for consultants, etc.?

* Given the Epic User Stories, the values, and the efinitions of done, what sort of work place, tools and technology set up are indicated?

* What is the general approach we are taking? What will be the length of our Sprints? What is the Road Map -- the key release points? How many teams will there be? If there are multiple teams, how will the Scrum Masters and the Product Owners from the multiple teams work together?

At the end of Sprint Zero, the Product Backlog must contain enough prioritized Stories to fill at least the first Release. Ideally, there would be enough Stories for two or three releases, so that the broad outlines of the technology and personnel needed can be understood.

Here's a possible outline for Sprint Zero:
Determine the length of sprints
Identify business value (the criteria to prioritize Stories)
Create epics. Prioritize epics (consider relative business value)
For the highest priority epic, turn the epic into stories
Prioritize the stories (consider relative business value)
For each story, create a definition of done
Create a team(s) workspace(s), and provide appropriate technology
Configure the team(s)

The following sections explain the Scrum terms needed to understand Sprint Zero work.

===User Stories===

We've been talking about ranking the features that make up the Product Backlog. In Scrum, these features are called Stories. There is an art to defining a Scrum Story, as you might imagine. Stories often take this form:

As _[User]_____, I want _[feature]_______, so that __[value]______.

An example:

* As a fabricator making a CNC Torch Table, I want complete and accurate CAD drawings, so that my efforts will result in a well-functioning machine.

Because the User is included in defining the feature, these are known as User Stories. The following video explains a good way to evaluate and improve User Stories, which are the list of features that make up the Product Backlog.

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=L_NyCczp0Fk&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.

To review the key ideas of the video:

'''Independent''' – dependencies among or between Stories need to be identified, eliminated, or tracked. An example of dependency: the training video for making a machine cannot be made until the machine is designed.
'''Negotiable''' – the Product Owner and the Team co-create the value and attributes of features (Stories)
'''Valuable''' – all Stories are connected directly to business value.
'''Estimable''' – the Team estimates the size of the Stories relative to each other.
'''Small''' – an important concept is raised here. Stories that are coming up in priority in the first or second Release should be small enough to be finished in one Sprint. Stories that are being implemented later can be large (Epics – more on this below).
'''Testable''' – knowing how we will know the Story is done, also called knowing the Definition of Done.

This review of the qualities of a good User Story gives some idea of the work to be done during Sprint Zero, while the User Stories are created, combined in one list, and then prioritized to make up the Product Backlog.

===Epic User Stories===

During Sprint Zero, the Product Owner will create a list of Epics. Epics are very large Stories. An example:
* As OSE, I want complete training materials in English for the 50 tools in GVCS on DVD, so that anyone with moderate experience in fabrication, and with access to the necessary tools and materials, can fabricate any of the 50 tools.

The list of Epics doesn't have to be exhaustive, but it should be thoroughly discussed and described, using the criteria for Stories developed in the video above.

===Definition of Done===

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=9FnZsaRujpw&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
NOTE -- this video is LOUD!

Review of the main concepts of the video:

This video is from Agile; Scrum is one form of Agile. So in this video you don't see mention of a Scrum Master. Instead they talk about a Team Lead. However, the content on Definition of Done is relevant for OSE.

In this video he is discussing creating the Definition of Done at the Team level. The Product Owner needs to first supply the Team with an initial Definition of Done feature by feature. The Product Owner's Definition of Done revolves around the What (and explains the Why). The Team's Definition of Done defines the How.

One value of this video is that it stresses how all members of a multi-functional Team get involved in creating the Definition of Done. It is crucial that this Definition is agreed to by everyone on the Team. When the Team commits to the work included in a Release, and in each Sprint, they are doing so based on the agreed on Definition of Done for each Story.

There is quite a bit of excess jargon in this video, but have patience, and relate it to GVCS. For example, we not only need to have the machine design "done," but also CAD drawings, an instructional video, and many other instructional components. Unifying the release and "done-ness" of all of these is what seems like the best, and most radical!, contribution Scrum can make to GVCS. These underlying points of “What is Done?” are crucial for us to understand the work that is needed in Sprint Zero.

==OSE [[GVCS]] Scrum==

OSE already has many of the pieces necessary to Scrum. There has been a lot of thought put into how to maximize the value of the project, the resulting list of GVCS machines, and the step-by-step process needed make them. All the work that has already been done would be used as the ground work for a [[#Sprint ZERO]].

The main question seems to be, who would do the work of Sprint Zero for OSE. It seems that [[Marcin Jakubowski|Marcin]] needs to be centrally involved in the first three steps of Sprint Zero. In addition to Marcin for those first three steps, at minimum a Scrum Master would be needed. This is when the input Marcin brought back from TED in March (redistributing economic justice?) will be integrated into the current vision.

For the next two steps, turning the highest priority Epic into Stories, and prioritizing the Stories, another person(s) could step in for Marcin, if that seems best for OSE.

The need for Subject Matter Experts arises in the next step, creating the initial Definition of Done for each Story. An example of this would be creating standards for instructional videos, and ways to objectively measure if the instructional video for a certain machine meets those standards.

The real creative work needed to get ready for OSE Scrum involves understanding the incremental Releases, in other words, getting a vision of the order in which OSE "products" (the plans and documentation for each machine) will appear in the Product Backlog. The current list of [[GVCS Development Template#Process|31 steps]] needs to be reconfigured into Stories, and understood in terms of interim products that can be brought to the state of Done. The dependencies among the steps need to be charted out. This process will be used over and over, so getting it well understood, with really clear Definitions of Done, will help tremendously. The order in which the Stories from the 31 Steps appear will be a combination of the chronological dependencies of the steps, and the relative value of the Stories.

==Adapting Scrum to Hardware Technologies==

These comments come from a blog post.<ref>{{cite web
| last = Maccherone
| first = Larry
| title = Top 10 questions when using Agile on hardware projects
| date = February 23, 2010
| url = http://maccherone.com/larry/2010/02/23/top-10-questions-when-using-agile-on-hardware-projects/
| format = blog
| doi =
| accessdate = March 1, 2012}}</ref>

==Notes==
<references />

==See Also==

* [http://www.scrumhw.org/ Scrum for Hardware Product Development] ''Bringing Scrum to the Hardware Product Development Community''
* [http://maccherone.com/larry/2010/02/23/top-10-questions-when-using-agile-on-hardware-projects/ Top 10 questions when using Agile on hardware projects]

[[Category:Project Management]]

Scrum

2012-03-06T01:03:40Z

Mia Van Meter: /* Notes */

Definition: '''[[wikipedia:Scrum (development)|Scrum]]''' is an iterative and incremental methodology for software projects and product- or application-development. It is also one of the variants of [[wikipedia:agile software development|agile software development]] methodologies.

==Why would a development team use Scrum?==

As demonstrated by high-powered software teams around the world, the Scrum process can increase a development team's efficiency dramatically. In recent years, some Scrum coaches (Scrum Masters) can consistently get development teams to be six times more efficient, and it is becoming almost unremarkable for a Scrum Master to kick a team into a productive state 15 times more productive than in their pre-Scrum days.

Scrum is essentially a double handful of rules for how a team should work together, and how they should be managed. Underneath those rules is a profound understanding of human nature. What motivates us? That is the essential question which Scrum answers. Scrum rules are designed to instill ownership, motivation, and creative problem-solving in team members. The dramatic results of a well-functioning Scrum team come from the synchronistic multiplying effect of a group of developers working “in the flow.” [http://en.wikipedia.org/wiki/Jeff_Sutherland/ Jeff Sutherland], one of the creators of Scrum, refers to these as “activated” teams.

Following [http://en.wikipedia.org/wiki/Lean_software_development/ Lean] development principles, the rules of Scrum are stripped down to the essentials. One of the implications of this is that teams must adopt all the Scrum rules in order to get Scrum results. Jeff Sutherland's favorite lecture topic seems to be “Scrumbutt.” This occurs when teams say, “Yes, we're doing Scrum, but...” and explain an aspect of Scrum they decided not to implement. According to Sutherland, you cannot get dramatic results unless you are pretty much a Scrum purist. That said, Scrum can “wrap around” other software development process technologies like, for example, XP or Lean. It's not essential to understand those technologies fully, for our purposes, but they are mentioned in the discussion on this page.

The most relevant question for a project like OSE is – is Scrum applicable outside the software development world? This is the answer that Joe Justice and the WikiSpeed team answer with a resounding “Yes!” In the 10-minute TEDX talk below, he explains briefly how the WikiSpeed Team, a collection of 44 volunteers in 4 countries, in three months used Scrum and associated processes to design and build a road-certifiable 4-person commuter car that can get over 100 miles per gallon in standard EPA road tests. The relevance of this to OSE is obvious – a distributed team of volunteers co-developing revolutionary hardware, sound familiar? It's well worth your while to spend a few hours absorbing the information on Scrum that this page points to, and to help explore its relevance for OSE in general, and the GVCS in particular.

In this video, Joe Justice, of WikiSpeed, explains the process his all-volunteer design team used to exceed expectations in their fuel-efficient car design.

<html><iframe width="300" height="182" src="http://www.youtube.com/watch?v=x8jdx-lf2Dw" frameborder="0" allowfullscreen></iframe></html>

.
.

.
.

==What is Scrum?==

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/watch?v=Q5k7a9YEoUI" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
The video above is a great first introduction to Scrum! It's fast paced, and the graphics easily convey the important information.

Of course, like any single Scrum coach, this one has his own take on Scrum, and in some instances it's likely that OSE Scrum will be different.

To review his core concepts:

Roles: Product Owner, Scrum Master, Team Members (developers, testers, customers)

Release Planning:
*Product Backlog– Estimate for each feature wanted in product.
*Release Backlog
*plan 4-12 Sprints – a substantive back log to a ship-ready state
*Sprint Backlog

Burndown Chart – day by day measure of the amount of work left in a Release, or Sprint

Bugs – have a separate Defect Backlog. Resolve bugs within the Sprint.

Daily Scrum – short, standing, identify bugs.

So that video is a great introduction to Scrum, but how would we actually get started?

The Scrum process starts with the Product Owner. They are responsible for creating the Product Backlog, creating the Development Team, and for providing the Team with the tools necessary for them to work. The Scrum Master helps the Product Owner with these tasks.

===Sprint ZERO===

To get ready for the first development Sprint, the Product Owner and the Scrum Master need to meet together, and with the Team, and do some initial preparation. The amount of time spent on Sprint Zero should be limited, and agreed upon in advance. Unfinished preparation can be added to the Product Backlog when Sprint Zero is finished. Additionally, the task of adding to the Product Backlog, and refining features that are down the road a bit, will be ongoing tasks for the Product Owner.

The most important outcome of Sprint Zero is to create understanding about the value of the work. Given that OSE might choose to have a team (Scrum) of Product Owners, it could make implementation more clear if the business values we are creating are explicitly ranked. Usually the process of identifying and clarifying the business value is held more distantly from the Team. In the case of OSE, it seems likely that a group of people will be determining the relative priorities of our business values, and the relative rankings of the features that we're planning on creating.

Here are some further questions to be taken up during Sprint Zero:
* Do we have the right people with the right skills? Is there a need for consultants, etc.?

* Given the Epic User Stories, the values, and the efinitions of done, what sort of work place, tools and technology set up are indicated?

* What is the general approach we are taking? What will be the length of our Sprints? What is the Road Map -- the key release points? How many teams will there be? If there are multiple teams, how will the Scrum Masters and the Product Owners from the multiple teams work together?

At the end of Sprint Zero, the Product Backlog must contain enough prioritized Stories to fill at least the first Release. Ideally, there would be enough Stories for two or three releases, so that the broad outlines of the technology and personnel needed can be understood.

Here's a possible outline for Sprint Zero:
Determine the length of sprints
Identify business value (the criteria to prioritize Stories)
Create epics. Prioritize epics (consider relative business value)
For the highest priority epic, turn the epic into stories
Prioritize the stories (consider relative business value)
For each story, create a definition of done
Create a team(s) workspace(s), and provide appropriate technology
Configure the team(s)

The following sections explain the Scrum terms needed to understand Sprint Zero work.

===User Stories===

We've been talking about ranking the features that make up the Product Backlog. In Scrum, these features are called Stories. There is an art to defining a Scrum Story, as you might imagine. Stories often take this form:

As _[User]_____, I want _[feature]_______, so that __[value]______.

An example:

* As a fabricator making a CNC Torch Table, I want complete and accurate CAD drawings, so that my efforts will result in a well-functioning machine.

Because the User is included in defining the feature, these are known as User Stories. The following video explains a good way to evaluate and improve User Stories, which are the list of features that make up the Product Backlog.

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=L_NyCczp0Fk&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.

To review the key ideas of the video:

'''Independent''' – dependencies among or between Stories need to be identified, eliminated, or tracked. An example of dependency: the training video for making a machine cannot be made until the machine is designed.
'''Negotiable''' – the Product Owner and the Team co-create the value and attributes of features (Stories)
'''Valuable''' – all Stories are connected directly to business value.
'''Estimable''' – the Team estimates the size of the Stories relative to each other.
'''Small''' – an important concept is raised here. Stories that are coming up in priority in the first or second Release should be small enough to be finished in one Sprint. Stories that are being implemented later can be large (Epics – more on this below).
'''Testable''' – knowing how we will know the Story is done, also called knowing the Definition of Done.

This review of the qualities of a good User Story gives some idea of the work to be done during Sprint Zero, while the User Stories are created, combined in one list, and then prioritized to make up the Product Backlog.

===Epic User Stories===

During Sprint Zero, the Product Owner will create a list of Epics. Epics are very large Stories. An example:
* As OSE, I want complete training materials in English for the 50 tools in GVCS on DVD, so that anyone with moderate experience in fabrication, and with access to the necessary tools and materials, can fabricate any of the 50 tools.

The list of Epics doesn't have to be exhaustive, but it should be thoroughly discussed and described, using the criteria for Stories developed in the video above.

===Definition of Done===

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=9FnZsaRujpw&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
NOTE -- this video is LOUD!

Review of the main concepts of the video:

This video is from Agile; Scrum is one form of Agile. So in this video you don't see mention of a Scrum Master. Instead they talk about a Team Lead. However, the content on Definition of Done is relevant for OSE.

In this video he is discussing creating the Definition of Done at the Team level. The Product Owner needs to first supply the Team with an initial Definition of Done feature by feature. The Product Owner's Definition of Done revolves around the What (and explains the Why). The Team's Definition of Done defines the How.

One value of this video is that it stresses how all members of a multi-functional Team get involved in creating the Definition of Done. It is crucial that this Definition is agreed to by everyone on the Team. When the Team commits to the work included in a Release, and in each Sprint, they are doing so based on the agreed on Definition of Done for each Story.

There is quite a bit of excess jargon in this video, but have patience, and relate it to GVCS. For example, we not only need to have the machine design "done," but also CAD drawings, an instructional video, and many other instructional components. Unifying the release and "done-ness" of all of these is what seems like the best, and most radical!, contribution Scrum can make to GVCS. These underlying points of “What is Done?” are crucial for us to understand the work that is needed in Sprint Zero.

==OSE [[GVCS]] Scrum==

OSE already has many of the pieces necessary to Scrum. There has been a lot of thought put into how to maximize the value of the project, the resulting list of GVCS machines, and the step-by-step process needed make them. All the work that has already been done would be used as the ground work for a [[#Sprint ZERO]].

The main question seems to be, who would do the work of Sprint Zero for OSE. It seems that [[Marcin Jakubowski|Marcin]] needs to be centrally involved in the first three steps of Sprint Zero. In addition to Marcin for those first three steps, at minimum a Scrum Master would be needed. This is when the input Marcin brought back from TED in March (redistributing economic justice?) will be integrated into the current vision.

For the next two steps, turning the highest priority Epic into Stories, and prioritizing the Stories, another person(s) could step in for Marcin, if that seems best for OSE.

The need for Subject Matter Experts arises in the next step, creating the initial Definition of Done for each Story. An example of this would be creating standards for instructional videos, and ways to objectively measure if the instructional video for a certain machine meets those standards.

The real creative work needed to get ready for OSE Scrum involves understanding the incremental Releases, in other words, getting a vision of the order in which OSE "products" (the plans and documentation for each machine) will appear in the Product Backlog. The current list of [[GVCS Development Template#Process|31 steps]] needs to be reconfigured into Stories, and understood in terms of interim products that can be brought to the state of Done. The dependencies among the steps need to be charted out. This process will be used over and over, so getting it well understood, with really clear Definitions of Done, will help tremendously. The order in which the Stories from the 31 Steps appear will be a combination of the chronological dependencies of the steps, and the relative value of the Stories.

==Adapting Scrum to Hardware Technologies==

These comments come from a blog post.<ref>{{cite web
| last = Maccherone
| first = Larry
| title = Top 10 questions when using Agile on hardware projects
| date = February 23, 2010
| url = http://maccherone.com/larry/2010/02/23/top-10-questions-when-using-agile-on-hardware-projects/
| format = blog
| doi =
| accessdate = March 1, 2012}}</ref>

==Notes==
{{reflist}}

==See Also==

* [http://www.scrumhw.org/ Scrum for Hardware Product Development] ''Bringing Scrum to the Hardware Product Development Community''
* [http://maccherone.com/larry/2010/02/23/top-10-questions-when-using-agile-on-hardware-projects/ Top 10 questions when using Agile on hardware projects]

[[Category:Project Management]]

Scrum

2012-03-06T01:02:08Z

Mia Van Meter: /* Adapting Scrum to Hardware Technologies */

Definition: '''[[wikipedia:Scrum (development)|Scrum]]''' is an iterative and incremental methodology for software projects and product- or application-development. It is also one of the variants of [[wikipedia:agile software development|agile software development]] methodologies.

==Why would a development team use Scrum?==

As demonstrated by high-powered software teams around the world, the Scrum process can increase a development team's efficiency dramatically. In recent years, some Scrum coaches (Scrum Masters) can consistently get development teams to be six times more efficient, and it is becoming almost unremarkable for a Scrum Master to kick a team into a productive state 15 times more productive than in their pre-Scrum days.

Scrum is essentially a double handful of rules for how a team should work together, and how they should be managed. Underneath those rules is a profound understanding of human nature. What motivates us? That is the essential question which Scrum answers. Scrum rules are designed to instill ownership, motivation, and creative problem-solving in team members. The dramatic results of a well-functioning Scrum team come from the synchronistic multiplying effect of a group of developers working “in the flow.” [http://en.wikipedia.org/wiki/Jeff_Sutherland/ Jeff Sutherland], one of the creators of Scrum, refers to these as “activated” teams.

Following [http://en.wikipedia.org/wiki/Lean_software_development/ Lean] development principles, the rules of Scrum are stripped down to the essentials. One of the implications of this is that teams must adopt all the Scrum rules in order to get Scrum results. Jeff Sutherland's favorite lecture topic seems to be “Scrumbutt.” This occurs when teams say, “Yes, we're doing Scrum, but...” and explain an aspect of Scrum they decided not to implement. According to Sutherland, you cannot get dramatic results unless you are pretty much a Scrum purist. That said, Scrum can “wrap around” other software development process technologies like, for example, XP or Lean. It's not essential to understand those technologies fully, for our purposes, but they are mentioned in the discussion on this page.

The most relevant question for a project like OSE is – is Scrum applicable outside the software development world? This is the answer that Joe Justice and the WikiSpeed team answer with a resounding “Yes!” In the 10-minute TEDX talk below, he explains briefly how the WikiSpeed Team, a collection of 44 volunteers in 4 countries, in three months used Scrum and associated processes to design and build a road-certifiable 4-person commuter car that can get over 100 miles per gallon in standard EPA road tests. The relevance of this to OSE is obvious – a distributed team of volunteers co-developing revolutionary hardware, sound familiar? It's well worth your while to spend a few hours absorbing the information on Scrum that this page points to, and to help explore its relevance for OSE in general, and the GVCS in particular.

In this video, Joe Justice, of WikiSpeed, explains the process his all-volunteer design team used to exceed expectations in their fuel-efficient car design.

<html><iframe width="300" height="182" src="http://www.youtube.com/watch?v=x8jdx-lf2Dw" frameborder="0" allowfullscreen></iframe></html>

.
.

.
.

==What is Scrum?==

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/watch?v=Q5k7a9YEoUI" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
The video above is a great first introduction to Scrum! It's fast paced, and the graphics easily convey the important information.

Of course, like any single Scrum coach, this one has his own take on Scrum, and in some instances it's likely that OSE Scrum will be different.

To review his core concepts:

Roles: Product Owner, Scrum Master, Team Members (developers, testers, customers)

Release Planning:
*Product Backlog– Estimate for each feature wanted in product.
*Release Backlog
*plan 4-12 Sprints – a substantive back log to a ship-ready state
*Sprint Backlog

Burndown Chart – day by day measure of the amount of work left in a Release, or Sprint

Bugs – have a separate Defect Backlog. Resolve bugs within the Sprint.

Daily Scrum – short, standing, identify bugs.

So that video is a great introduction to Scrum, but how would we actually get started?

The Scrum process starts with the Product Owner. They are responsible for creating the Product Backlog, creating the Development Team, and for providing the Team with the tools necessary for them to work. The Scrum Master helps the Product Owner with these tasks.

===Sprint ZERO===

To get ready for the first development Sprint, the Product Owner and the Scrum Master need to meet together, and with the Team, and do some initial preparation. The amount of time spent on Sprint Zero should be limited, and agreed upon in advance. Unfinished preparation can be added to the Product Backlog when Sprint Zero is finished. Additionally, the task of adding to the Product Backlog, and refining features that are down the road a bit, will be ongoing tasks for the Product Owner.

The most important outcome of Sprint Zero is to create understanding about the value of the work. Given that OSE might choose to have a team (Scrum) of Product Owners, it could make implementation more clear if the business values we are creating are explicitly ranked. Usually the process of identifying and clarifying the business value is held more distantly from the Team. In the case of OSE, it seems likely that a group of people will be determining the relative priorities of our business values, and the relative rankings of the features that we're planning on creating.

Here are some further questions to be taken up during Sprint Zero:
* Do we have the right people with the right skills? Is there a need for consultants, etc.?

* Given the Epic User Stories, the values, and the efinitions of done, what sort of work place, tools and technology set up are indicated?

* What is the general approach we are taking? What will be the length of our Sprints? What is the Road Map -- the key release points? How many teams will there be? If there are multiple teams, how will the Scrum Masters and the Product Owners from the multiple teams work together?

At the end of Sprint Zero, the Product Backlog must contain enough prioritized Stories to fill at least the first Release. Ideally, there would be enough Stories for two or three releases, so that the broad outlines of the technology and personnel needed can be understood.

Here's a possible outline for Sprint Zero:
Determine the length of sprints
Identify business value (the criteria to prioritize Stories)
Create epics. Prioritize epics (consider relative business value)
For the highest priority epic, turn the epic into stories
Prioritize the stories (consider relative business value)
For each story, create a definition of done
Create a team(s) workspace(s), and provide appropriate technology
Configure the team(s)

The following sections explain the Scrum terms needed to understand Sprint Zero work.

===User Stories===

We've been talking about ranking the features that make up the Product Backlog. In Scrum, these features are called Stories. There is an art to defining a Scrum Story, as you might imagine. Stories often take this form:

As _[User]_____, I want _[feature]_______, so that __[value]______.

An example:

* As a fabricator making a CNC Torch Table, I want complete and accurate CAD drawings, so that my efforts will result in a well-functioning machine.

Because the User is included in defining the feature, these are known as User Stories. The following video explains a good way to evaluate and improve User Stories, which are the list of features that make up the Product Backlog.

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=L_NyCczp0Fk&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.

To review the key ideas of the video:

'''Independent''' – dependencies among or between Stories need to be identified, eliminated, or tracked. An example of dependency: the training video for making a machine cannot be made until the machine is designed.
'''Negotiable''' – the Product Owner and the Team co-create the value and attributes of features (Stories)
'''Valuable''' – all Stories are connected directly to business value.
'''Estimable''' – the Team estimates the size of the Stories relative to each other.
'''Small''' – an important concept is raised here. Stories that are coming up in priority in the first or second Release should be small enough to be finished in one Sprint. Stories that are being implemented later can be large (Epics – more on this below).
'''Testable''' – knowing how we will know the Story is done, also called knowing the Definition of Done.

This review of the qualities of a good User Story gives some idea of the work to be done during Sprint Zero, while the User Stories are created, combined in one list, and then prioritized to make up the Product Backlog.

===Epic User Stories===

During Sprint Zero, the Product Owner will create a list of Epics. Epics are very large Stories. An example:
* As OSE, I want complete training materials in English for the 50 tools in GVCS on DVD, so that anyone with moderate experience in fabrication, and with access to the necessary tools and materials, can fabricate any of the 50 tools.

The list of Epics doesn't have to be exhaustive, but it should be thoroughly discussed and described, using the criteria for Stories developed in the video above.

===Definition of Done===

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=9FnZsaRujpw&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
NOTE -- this video is LOUD!

Review of the main concepts of the video:

This video is from Agile; Scrum is one form of Agile. So in this video you don't see mention of a Scrum Master. Instead they talk about a Team Lead. However, the content on Definition of Done is relevant for OSE.

In this video he is discussing creating the Definition of Done at the Team level. The Product Owner needs to first supply the Team with an initial Definition of Done feature by feature. The Product Owner's Definition of Done revolves around the What (and explains the Why). The Team's Definition of Done defines the How.

One value of this video is that it stresses how all members of a multi-functional Team get involved in creating the Definition of Done. It is crucial that this Definition is agreed to by everyone on the Team. When the Team commits to the work included in a Release, and in each Sprint, they are doing so based on the agreed on Definition of Done for each Story.

There is quite a bit of excess jargon in this video, but have patience, and relate it to GVCS. For example, we not only need to have the machine design "done," but also CAD drawings, an instructional video, and many other instructional components. Unifying the release and "done-ness" of all of these is what seems like the best, and most radical!, contribution Scrum can make to GVCS. These underlying points of “What is Done?” are crucial for us to understand the work that is needed in Sprint Zero.

==OSE [[GVCS]] Scrum==

OSE already has many of the pieces necessary to Scrum. There has been a lot of thought put into how to maximize the value of the project, the resulting list of GVCS machines, and the step-by-step process needed make them. All the work that has already been done would be used as the ground work for a [[#Sprint ZERO]].

The main question seems to be, who would do the work of Sprint Zero for OSE. It seems that [[Marcin Jakubowski|Marcin]] needs to be centrally involved in the first three steps of Sprint Zero. In addition to Marcin for those first three steps, at minimum a Scrum Master would be needed. This is when the input Marcin brought back from TED in March (redistributing economic justice?) will be integrated into the current vision.

For the next two steps, turning the highest priority Epic into Stories, and prioritizing the Stories, another person(s) could step in for Marcin, if that seems best for OSE.

The need for Subject Matter Experts arises in the next step, creating the initial Definition of Done for each Story. An example of this would be creating standards for instructional videos, and ways to objectively measure if the instructional video for a certain machine meets those standards.

The real creative work needed to get ready for OSE Scrum involves understanding the incremental Releases, in other words, getting a vision of the order in which OSE "products" (the plans and documentation for each machine) will appear in the Product Backlog. The current list of [[GVCS Development Template#Process|31 steps]] needs to be reconfigured into Stories, and understood in terms of interim products that can be brought to the state of Done. The dependencies among the steps need to be charted out. This process will be used over and over, so getting it well understood, with really clear Definitions of Done, will help tremendously. The order in which the Stories from the 31 Steps appear will be a combination of the chronological dependencies of the steps, and the relative value of the Stories.

==Adapting Scrum to Hardware Technologies==

These comments come from a blog post.<ref>{{cite web
| last = Maccherone
| first = Larry
| title = Top 10 questions when using Agile on hardware projects
| date = February 23, 2010
| url = http://maccherone.com/larry/2010/02/23/top-10-questions-when-using-agile-on-hardware-projects/
| format = blog
| doi =
| accessdate = March 1, 2012}}</ref>

==Notes==
<references />

==See Also==

* [http://www.scrumhw.org/ Scrum for Hardware Product Development] ''Bringing Scrum to the Hardware Product Development Community''
* [http://maccherone.com/larry/2010/02/23/top-10-questions-when-using-agile-on-hardware-projects/ Top 10 questions when using Agile on hardware projects]

[[Category:Project Management]]

Scrum

2012-03-06T01:01:05Z

Mia Van Meter: /* Adapting Scrum to Hardware Technologies */

Definition: '''[[wikipedia:Scrum (development)|Scrum]]''' is an iterative and incremental methodology for software projects and product- or application-development. It is also one of the variants of [[wikipedia:agile software development|agile software development]] methodologies.

==Why would a development team use Scrum?==

As demonstrated by high-powered software teams around the world, the Scrum process can increase a development team's efficiency dramatically. In recent years, some Scrum coaches (Scrum Masters) can consistently get development teams to be six times more efficient, and it is becoming almost unremarkable for a Scrum Master to kick a team into a productive state 15 times more productive than in their pre-Scrum days.

Scrum is essentially a double handful of rules for how a team should work together, and how they should be managed. Underneath those rules is a profound understanding of human nature. What motivates us? That is the essential question which Scrum answers. Scrum rules are designed to instill ownership, motivation, and creative problem-solving in team members. The dramatic results of a well-functioning Scrum team come from the synchronistic multiplying effect of a group of developers working “in the flow.” [http://en.wikipedia.org/wiki/Jeff_Sutherland/ Jeff Sutherland], one of the creators of Scrum, refers to these as “activated” teams.

Following [http://en.wikipedia.org/wiki/Lean_software_development/ Lean] development principles, the rules of Scrum are stripped down to the essentials. One of the implications of this is that teams must adopt all the Scrum rules in order to get Scrum results. Jeff Sutherland's favorite lecture topic seems to be “Scrumbutt.” This occurs when teams say, “Yes, we're doing Scrum, but...” and explain an aspect of Scrum they decided not to implement. According to Sutherland, you cannot get dramatic results unless you are pretty much a Scrum purist. That said, Scrum can “wrap around” other software development process technologies like, for example, XP or Lean. It's not essential to understand those technologies fully, for our purposes, but they are mentioned in the discussion on this page.

The most relevant question for a project like OSE is – is Scrum applicable outside the software development world? This is the answer that Joe Justice and the WikiSpeed team answer with a resounding “Yes!” In the 10-minute TEDX talk below, he explains briefly how the WikiSpeed Team, a collection of 44 volunteers in 4 countries, in three months used Scrum and associated processes to design and build a road-certifiable 4-person commuter car that can get over 100 miles per gallon in standard EPA road tests. The relevance of this to OSE is obvious – a distributed team of volunteers co-developing revolutionary hardware, sound familiar? It's well worth your while to spend a few hours absorbing the information on Scrum that this page points to, and to help explore its relevance for OSE in general, and the GVCS in particular.

In this video, Joe Justice, of WikiSpeed, explains the process his all-volunteer design team used to exceed expectations in their fuel-efficient car design.

<html><iframe width="300" height="182" src="http://www.youtube.com/watch?v=x8jdx-lf2Dw" frameborder="0" allowfullscreen></iframe></html>

.
.

.
.

==What is Scrum?==

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/watch?v=Q5k7a9YEoUI" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
The video above is a great first introduction to Scrum! It's fast paced, and the graphics easily convey the important information.

Of course, like any single Scrum coach, this one has his own take on Scrum, and in some instances it's likely that OSE Scrum will be different.

To review his core concepts:

Roles: Product Owner, Scrum Master, Team Members (developers, testers, customers)

Release Planning:
*Product Backlog– Estimate for each feature wanted in product.
*Release Backlog
*plan 4-12 Sprints – a substantive back log to a ship-ready state
*Sprint Backlog

Burndown Chart – day by day measure of the amount of work left in a Release, or Sprint

Bugs – have a separate Defect Backlog. Resolve bugs within the Sprint.

Daily Scrum – short, standing, identify bugs.

So that video is a great introduction to Scrum, but how would we actually get started?

The Scrum process starts with the Product Owner. They are responsible for creating the Product Backlog, creating the Development Team, and for providing the Team with the tools necessary for them to work. The Scrum Master helps the Product Owner with these tasks.

===Sprint ZERO===

To get ready for the first development Sprint, the Product Owner and the Scrum Master need to meet together, and with the Team, and do some initial preparation. The amount of time spent on Sprint Zero should be limited, and agreed upon in advance. Unfinished preparation can be added to the Product Backlog when Sprint Zero is finished. Additionally, the task of adding to the Product Backlog, and refining features that are down the road a bit, will be ongoing tasks for the Product Owner.

The most important outcome of Sprint Zero is to create understanding about the value of the work. Given that OSE might choose to have a team (Scrum) of Product Owners, it could make implementation more clear if the business values we are creating are explicitly ranked. Usually the process of identifying and clarifying the business value is held more distantly from the Team. In the case of OSE, it seems likely that a group of people will be determining the relative priorities of our business values, and the relative rankings of the features that we're planning on creating.

Here are some further questions to be taken up during Sprint Zero:
* Do we have the right people with the right skills? Is there a need for consultants, etc.?

* Given the Epic User Stories, the values, and the efinitions of done, what sort of work place, tools and technology set up are indicated?

* What is the general approach we are taking? What will be the length of our Sprints? What is the Road Map -- the key release points? How many teams will there be? If there are multiple teams, how will the Scrum Masters and the Product Owners from the multiple teams work together?

At the end of Sprint Zero, the Product Backlog must contain enough prioritized Stories to fill at least the first Release. Ideally, there would be enough Stories for two or three releases, so that the broad outlines of the technology and personnel needed can be understood.

Here's a possible outline for Sprint Zero:
Determine the length of sprints
Identify business value (the criteria to prioritize Stories)
Create epics. Prioritize epics (consider relative business value)
For the highest priority epic, turn the epic into stories
Prioritize the stories (consider relative business value)
For each story, create a definition of done
Create a team(s) workspace(s), and provide appropriate technology
Configure the team(s)

The following sections explain the Scrum terms needed to understand Sprint Zero work.

===User Stories===

We've been talking about ranking the features that make up the Product Backlog. In Scrum, these features are called Stories. There is an art to defining a Scrum Story, as you might imagine. Stories often take this form:

As _[User]_____, I want _[feature]_______, so that __[value]______.

An example:

* As a fabricator making a CNC Torch Table, I want complete and accurate CAD drawings, so that my efforts will result in a well-functioning machine.

Because the User is included in defining the feature, these are known as User Stories. The following video explains a good way to evaluate and improve User Stories, which are the list of features that make up the Product Backlog.

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=L_NyCczp0Fk&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.

To review the key ideas of the video:

'''Independent''' – dependencies among or between Stories need to be identified, eliminated, or tracked. An example of dependency: the training video for making a machine cannot be made until the machine is designed.
'''Negotiable''' – the Product Owner and the Team co-create the value and attributes of features (Stories)
'''Valuable''' – all Stories are connected directly to business value.
'''Estimable''' – the Team estimates the size of the Stories relative to each other.
'''Small''' – an important concept is raised here. Stories that are coming up in priority in the first or second Release should be small enough to be finished in one Sprint. Stories that are being implemented later can be large (Epics – more on this below).
'''Testable''' – knowing how we will know the Story is done, also called knowing the Definition of Done.

This review of the qualities of a good User Story gives some idea of the work to be done during Sprint Zero, while the User Stories are created, combined in one list, and then prioritized to make up the Product Backlog.

===Epic User Stories===

During Sprint Zero, the Product Owner will create a list of Epics. Epics are very large Stories. An example:
* As OSE, I want complete training materials in English for the 50 tools in GVCS on DVD, so that anyone with moderate experience in fabrication, and with access to the necessary tools and materials, can fabricate any of the 50 tools.

The list of Epics doesn't have to be exhaustive, but it should be thoroughly discussed and described, using the criteria for Stories developed in the video above.

===Definition of Done===

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=9FnZsaRujpw&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
NOTE -- this video is LOUD!

Review of the main concepts of the video:

This video is from Agile; Scrum is one form of Agile. So in this video you don't see mention of a Scrum Master. Instead they talk about a Team Lead. However, the content on Definition of Done is relevant for OSE.

In this video he is discussing creating the Definition of Done at the Team level. The Product Owner needs to first supply the Team with an initial Definition of Done feature by feature. The Product Owner's Definition of Done revolves around the What (and explains the Why). The Team's Definition of Done defines the How.

One value of this video is that it stresses how all members of a multi-functional Team get involved in creating the Definition of Done. It is crucial that this Definition is agreed to by everyone on the Team. When the Team commits to the work included in a Release, and in each Sprint, they are doing so based on the agreed on Definition of Done for each Story.

There is quite a bit of excess jargon in this video, but have patience, and relate it to GVCS. For example, we not only need to have the machine design "done," but also CAD drawings, an instructional video, and many other instructional components. Unifying the release and "done-ness" of all of these is what seems like the best, and most radical!, contribution Scrum can make to GVCS. These underlying points of “What is Done?” are crucial for us to understand the work that is needed in Sprint Zero.

==OSE [[GVCS]] Scrum==

OSE already has many of the pieces necessary to Scrum. There has been a lot of thought put into how to maximize the value of the project, the resulting list of GVCS machines, and the step-by-step process needed make them. All the work that has already been done would be used as the ground work for a [[#Sprint ZERO]].

The main question seems to be, who would do the work of Sprint Zero for OSE. It seems that [[Marcin Jakubowski|Marcin]] needs to be centrally involved in the first three steps of Sprint Zero. In addition to Marcin for those first three steps, at minimum a Scrum Master would be needed. This is when the input Marcin brought back from TED in March (redistributing economic justice?) will be integrated into the current vision.

For the next two steps, turning the highest priority Epic into Stories, and prioritizing the Stories, another person(s) could step in for Marcin, if that seems best for OSE.

The need for Subject Matter Experts arises in the next step, creating the initial Definition of Done for each Story. An example of this would be creating standards for instructional videos, and ways to objectively measure if the instructional video for a certain machine meets those standards.

The real creative work needed to get ready for OSE Scrum involves understanding the incremental Releases, in other words, getting a vision of the order in which OSE "products" (the plans and documentation for each machine) will appear in the Product Backlog. The current list of [[GVCS Development Template#Process|31 steps]] needs to be reconfigured into Stories, and understood in terms of interim products that can be brought to the state of Done. The dependencies among the steps need to be charted out. This process will be used over and over, so getting it well understood, with really clear Definitions of Done, will help tremendously. The order in which the Stories from the 31 Steps appear will be a combination of the chronological dependencies of the steps, and the relative value of the Stories.

==Adapting Scrum to Hardware Technologies==

These comments come from a blog post.<ref>{{cite web
| last = Maccherone
| first = Larry
| title = Top 10 questions when using Agile on hardware projects
| date = February 23, 2010
| url = http://maccherone.com/larry/2010/02/23/top-10-questions-when-using-agile-on-hardware-projects/
| format = blog
| doi =
| accessdate = March 1, 2012}}</ref>

==See Also==

* [http://www.scrumhw.org/ Scrum for Hardware Product Development] ''Bringing Scrum to the Hardware Product Development Community''
* [http://maccherone.com/larry/2010/02/23/top-10-questions-when-using-agile-on-hardware-projects/ Top 10 questions when using Agile on hardware projects]

[[Category:Project Management]]

Scrum

2012-03-06T01:00:24Z

Mia Van Meter: /* OSE GVCS Scrum */

Definition: '''[[wikipedia:Scrum (development)|Scrum]]''' is an iterative and incremental methodology for software projects and product- or application-development. It is also one of the variants of [[wikipedia:agile software development|agile software development]] methodologies.

==Why would a development team use Scrum?==

As demonstrated by high-powered software teams around the world, the Scrum process can increase a development team's efficiency dramatically. In recent years, some Scrum coaches (Scrum Masters) can consistently get development teams to be six times more efficient, and it is becoming almost unremarkable for a Scrum Master to kick a team into a productive state 15 times more productive than in their pre-Scrum days.

Scrum is essentially a double handful of rules for how a team should work together, and how they should be managed. Underneath those rules is a profound understanding of human nature. What motivates us? That is the essential question which Scrum answers. Scrum rules are designed to instill ownership, motivation, and creative problem-solving in team members. The dramatic results of a well-functioning Scrum team come from the synchronistic multiplying effect of a group of developers working “in the flow.” [http://en.wikipedia.org/wiki/Jeff_Sutherland/ Jeff Sutherland], one of the creators of Scrum, refers to these as “activated” teams.

Following [http://en.wikipedia.org/wiki/Lean_software_development/ Lean] development principles, the rules of Scrum are stripped down to the essentials. One of the implications of this is that teams must adopt all the Scrum rules in order to get Scrum results. Jeff Sutherland's favorite lecture topic seems to be “Scrumbutt.” This occurs when teams say, “Yes, we're doing Scrum, but...” and explain an aspect of Scrum they decided not to implement. According to Sutherland, you cannot get dramatic results unless you are pretty much a Scrum purist. That said, Scrum can “wrap around” other software development process technologies like, for example, XP or Lean. It's not essential to understand those technologies fully, for our purposes, but they are mentioned in the discussion on this page.

The most relevant question for a project like OSE is – is Scrum applicable outside the software development world? This is the answer that Joe Justice and the WikiSpeed team answer with a resounding “Yes!” In the 10-minute TEDX talk below, he explains briefly how the WikiSpeed Team, a collection of 44 volunteers in 4 countries, in three months used Scrum and associated processes to design and build a road-certifiable 4-person commuter car that can get over 100 miles per gallon in standard EPA road tests. The relevance of this to OSE is obvious – a distributed team of volunteers co-developing revolutionary hardware, sound familiar? It's well worth your while to spend a few hours absorbing the information on Scrum that this page points to, and to help explore its relevance for OSE in general, and the GVCS in particular.

In this video, Joe Justice, of WikiSpeed, explains the process his all-volunteer design team used to exceed expectations in their fuel-efficient car design.

<html><iframe width="300" height="182" src="http://www.youtube.com/watch?v=x8jdx-lf2Dw" frameborder="0" allowfullscreen></iframe></html>

.
.

.
.

==What is Scrum?==

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/watch?v=Q5k7a9YEoUI" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
The video above is a great first introduction to Scrum! It's fast paced, and the graphics easily convey the important information.

Of course, like any single Scrum coach, this one has his own take on Scrum, and in some instances it's likely that OSE Scrum will be different.

To review his core concepts:

Roles: Product Owner, Scrum Master, Team Members (developers, testers, customers)

Release Planning:
*Product Backlog– Estimate for each feature wanted in product.
*Release Backlog
*plan 4-12 Sprints – a substantive back log to a ship-ready state
*Sprint Backlog

Burndown Chart – day by day measure of the amount of work left in a Release, or Sprint

Bugs – have a separate Defect Backlog. Resolve bugs within the Sprint.

Daily Scrum – short, standing, identify bugs.

So that video is a great introduction to Scrum, but how would we actually get started?

The Scrum process starts with the Product Owner. They are responsible for creating the Product Backlog, creating the Development Team, and for providing the Team with the tools necessary for them to work. The Scrum Master helps the Product Owner with these tasks.

===Sprint ZERO===

To get ready for the first development Sprint, the Product Owner and the Scrum Master need to meet together, and with the Team, and do some initial preparation. The amount of time spent on Sprint Zero should be limited, and agreed upon in advance. Unfinished preparation can be added to the Product Backlog when Sprint Zero is finished. Additionally, the task of adding to the Product Backlog, and refining features that are down the road a bit, will be ongoing tasks for the Product Owner.

The most important outcome of Sprint Zero is to create understanding about the value of the work. Given that OSE might choose to have a team (Scrum) of Product Owners, it could make implementation more clear if the business values we are creating are explicitly ranked. Usually the process of identifying and clarifying the business value is held more distantly from the Team. In the case of OSE, it seems likely that a group of people will be determining the relative priorities of our business values, and the relative rankings of the features that we're planning on creating.

Here are some further questions to be taken up during Sprint Zero:
* Do we have the right people with the right skills? Is there a need for consultants, etc.?

* Given the Epic User Stories, the values, and the efinitions of done, what sort of work place, tools and technology set up are indicated?

* What is the general approach we are taking? What will be the length of our Sprints? What is the Road Map -- the key release points? How many teams will there be? If there are multiple teams, how will the Scrum Masters and the Product Owners from the multiple teams work together?

At the end of Sprint Zero, the Product Backlog must contain enough prioritized Stories to fill at least the first Release. Ideally, there would be enough Stories for two or three releases, so that the broad outlines of the technology and personnel needed can be understood.

Here's a possible outline for Sprint Zero:
Determine the length of sprints
Identify business value (the criteria to prioritize Stories)
Create epics. Prioritize epics (consider relative business value)
For the highest priority epic, turn the epic into stories
Prioritize the stories (consider relative business value)
For each story, create a definition of done
Create a team(s) workspace(s), and provide appropriate technology
Configure the team(s)

The following sections explain the Scrum terms needed to understand Sprint Zero work.

===User Stories===

We've been talking about ranking the features that make up the Product Backlog. In Scrum, these features are called Stories. There is an art to defining a Scrum Story, as you might imagine. Stories often take this form:

As _[User]_____, I want _[feature]_______, so that __[value]______.

An example:

* As a fabricator making a CNC Torch Table, I want complete and accurate CAD drawings, so that my efforts will result in a well-functioning machine.

Because the User is included in defining the feature, these are known as User Stories. The following video explains a good way to evaluate and improve User Stories, which are the list of features that make up the Product Backlog.

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=L_NyCczp0Fk&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.

To review the key ideas of the video:

'''Independent''' – dependencies among or between Stories need to be identified, eliminated, or tracked. An example of dependency: the training video for making a machine cannot be made until the machine is designed.
'''Negotiable''' – the Product Owner and the Team co-create the value and attributes of features (Stories)
'''Valuable''' – all Stories are connected directly to business value.
'''Estimable''' – the Team estimates the size of the Stories relative to each other.
'''Small''' – an important concept is raised here. Stories that are coming up in priority in the first or second Release should be small enough to be finished in one Sprint. Stories that are being implemented later can be large (Epics – more on this below).
'''Testable''' – knowing how we will know the Story is done, also called knowing the Definition of Done.

This review of the qualities of a good User Story gives some idea of the work to be done during Sprint Zero, while the User Stories are created, combined in one list, and then prioritized to make up the Product Backlog.

===Epic User Stories===

During Sprint Zero, the Product Owner will create a list of Epics. Epics are very large Stories. An example:
* As OSE, I want complete training materials in English for the 50 tools in GVCS on DVD, so that anyone with moderate experience in fabrication, and with access to the necessary tools and materials, can fabricate any of the 50 tools.

The list of Epics doesn't have to be exhaustive, but it should be thoroughly discussed and described, using the criteria for Stories developed in the video above.

===Definition of Done===

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=9FnZsaRujpw&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
NOTE -- this video is LOUD!

Review of the main concepts of the video:

This video is from Agile; Scrum is one form of Agile. So in this video you don't see mention of a Scrum Master. Instead they talk about a Team Lead. However, the content on Definition of Done is relevant for OSE.

In this video he is discussing creating the Definition of Done at the Team level. The Product Owner needs to first supply the Team with an initial Definition of Done feature by feature. The Product Owner's Definition of Done revolves around the What (and explains the Why). The Team's Definition of Done defines the How.

One value of this video is that it stresses how all members of a multi-functional Team get involved in creating the Definition of Done. It is crucial that this Definition is agreed to by everyone on the Team. When the Team commits to the work included in a Release, and in each Sprint, they are doing so based on the agreed on Definition of Done for each Story.

There is quite a bit of excess jargon in this video, but have patience, and relate it to GVCS. For example, we not only need to have the machine design "done," but also CAD drawings, an instructional video, and many other instructional components. Unifying the release and "done-ness" of all of these is what seems like the best, and most radical!, contribution Scrum can make to GVCS. These underlying points of “What is Done?” are crucial for us to understand the work that is needed in Sprint Zero.

==OSE [[GVCS]] Scrum==

OSE already has many of the pieces necessary to Scrum. There has been a lot of thought put into how to maximize the value of the project, the resulting list of GVCS machines, and the step-by-step process needed make them. All the work that has already been done would be used as the ground work for a [[#Sprint ZERO]].

The main question seems to be, who would do the work of Sprint Zero for OSE. It seems that [[Marcin Jakubowski|Marcin]] needs to be centrally involved in the first three steps of Sprint Zero. In addition to Marcin for those first three steps, at minimum a Scrum Master would be needed. This is when the input Marcin brought back from TED in March (redistributing economic justice?) will be integrated into the current vision.

For the next two steps, turning the highest priority Epic into Stories, and prioritizing the Stories, another person(s) could step in for Marcin, if that seems best for OSE.

The need for Subject Matter Experts arises in the next step, creating the initial Definition of Done for each Story. An example of this would be creating standards for instructional videos, and ways to objectively measure if the instructional video for a certain machine meets those standards.

The real creative work needed to get ready for OSE Scrum involves understanding the incremental Releases, in other words, getting a vision of the order in which OSE "products" (the plans and documentation for each machine) will appear in the Product Backlog. The current list of [[GVCS Development Template#Process|31 steps]] needs to be reconfigured into Stories, and understood in terms of interim products that can be brought to the state of Done. The dependencies among the steps need to be charted out. This process will be used over and over, so getting it well understood, with really clear Definitions of Done, will help tremendously. The order in which the Stories from the 31 Steps appear will be a combination of the chronological dependencies of the steps, and the relative value of the Stories.

==Adapting Scrum to Hardware Technologies==

These comments come from a blog post.<ref>{{cite web
| last = Maccherone
| first = Larry
| title = Top 10 questions when using Agile on hardware projects
| date = February 23, 2010
| url = http://maccherone.com/larry/2010/02/23/top-10-questions-when-using-agile-on-hardware-projects/
| format = blog
| doi =
| accessdate = March 1, 2012}}<ref>

==See Also==

* [http://www.scrumhw.org/ Scrum for Hardware Product Development] ''Bringing Scrum to the Hardware Product Development Community''
* [http://maccherone.com/larry/2010/02/23/top-10-questions-when-using-agile-on-hardware-projects/ Top 10 questions when using Agile on hardware projects]

[[Category:Project Management]]

Scrum

2012-03-05T23:41:06Z

Mia Van Meter: /* OSE GVCS Scrum */

Definition: '''[[wikipedia:Scrum (development)|Scrum]]''' is an iterative and incremental methodology for software projects and product- or application-development. It is also one of the variants of [[wikipedia:agile software development|agile software development]] methodologies.

==Why would a development team use Scrum?==

As demonstrated by high-powered software teams around the world, the Scrum process can increase a development team's efficiency dramatically. In recent years, some Scrum coaches (Scrum Masters) can consistently get development teams to be six times more efficient, and it is becoming almost unremarkable for a Scrum Master to kick a team into a productive state 15 times more productive than in their pre-Scrum days.

Scrum is essentially a double handful of rules for how a team should work together, and how they should be managed. Underneath those rules is a profound understanding of human nature. What motivates us? That is the essential question which Scrum answers. Scrum rules are designed to instill ownership, motivation, and creative problem-solving in team members. The dramatic results of a well-functioning Scrum team come from the synchronistic multiplying effect of a group of developers working “in the flow.” [http://en.wikipedia.org/wiki/Jeff_Sutherland/ Jeff Sutherland], one of the creators of Scrum, refers to these as “activated” teams.

Following [http://en.wikipedia.org/wiki/Lean_software_development/ Lean] development principles, the rules of Scrum are stripped down to the essentials. One of the implications of this is that teams must adopt all the Scrum rules in order to get Scrum results. Jeff Sutherland's favorite lecture topic seems to be “Scrumbutt.” This occurs when teams say, “Yes, we're doing Scrum, but...” and explain an aspect of Scrum they decided not to implement. According to Sutherland, you cannot get dramatic results unless you are pretty much a Scrum purist. That said, Scrum can “wrap around” other software development process technologies like, for example, XP or Lean. It's not essential to understand those technologies fully, for our purposes, but they are mentioned in the discussion on this page.

The most relevant question for a project like OSE is – is Scrum applicable outside the software development world? This is the answer that Joe Justice and the WikiSpeed team answer with a resounding “Yes!” In the 10-minute TEDX talk below, he explains briefly how the WikiSpeed Team, a collection of 44 volunteers in 4 countries, in three months used Scrum and associated processes to design and build a road-certifiable 4-person commuter car that can get over 100 miles per gallon in standard EPA road tests. The relevance of this to OSE is obvious – a distributed team of volunteers co-developing revolutionary hardware, sound familiar? It's well worth your while to spend a few hours absorbing the information on Scrum that this page points to, and to help explore its relevance for OSE in general, and the GVCS in particular.

In this video, Joe Justice, of WikiSpeed, explains the process his all-volunteer design team used to exceed expectations in their fuel-efficient car design.

<html><iframe width="300" height="182" src="http://www.youtube.com/watch?v=x8jdx-lf2Dw" frameborder="0" allowfullscreen></iframe></html>

.
.

.
.

==What is Scrum?==

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/watch?v=Q5k7a9YEoUI" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
The video above is a great first introduction to Scrum! It's fast paced, and the graphics easily convey the important information.

Of course, like any single Scrum coach, this one has his own take on Scrum, and in some instances it's likely that OSE Scrum will be different.

To review his core concepts:

Roles: Product Owner, Scrum Master, Team Members (developers, testers, customers)

Release Planning:
*Product Backlog– Estimate for each feature wanted in product.
*Release Backlog
*plan 4-12 Sprints – a substantive back log to a ship-ready state
*Sprint Backlog

Burndown Chart – day by day measure of the amount of work left in a Release, or Sprint

Bugs – have a separate Defect Backlog. Resolve bugs within the Sprint.

Daily Scrum – short, standing, identify bugs.

So that video is a great introduction to Scrum, but how would we actually get started?

The Scrum process starts with the Product Owner. They are responsible for creating the Product Backlog, creating the Development Team, and for providing the Team with the tools necessary for them to work. The Scrum Master helps the Product Owner with these tasks.

===Sprint ZERO===

To get ready for the first development Sprint, the Product Owner and the Scrum Master need to meet together, and with the Team, and do some initial preparation. The amount of time spent on Sprint Zero should be limited, and agreed upon in advance. Unfinished preparation can be added to the Product Backlog when Sprint Zero is finished. Additionally, the task of adding to the Product Backlog, and refining features that are down the road a bit, will be ongoing tasks for the Product Owner.

The most important outcome of Sprint Zero is to create understanding about the value of the work. Given that OSE might choose to have a team (Scrum) of Product Owners, it could make implementation more clear if the business values we are creating are explicitly ranked. Usually the process of identifying and clarifying the business value is held more distantly from the Team. In the case of OSE, it seems likely that a group of people will be determining the relative priorities of our business values, and the relative rankings of the features that we're planning on creating.

Here are some further questions to be taken up during Sprint Zero:
* Do we have the right people with the right skills? Is there a need for consultants, etc.?

* Given the Epic User Stories, the values, and the efinitions of done, what sort of work place, tools and technology set up are indicated?

* What is the general approach we are taking? What will be the length of our Sprints? What is the Road Map -- the key release points? How many teams will there be? If there are multiple teams, how will the Scrum Masters and the Product Owners from the multiple teams work together?

At the end of Sprint Zero, the Product Backlog must contain enough prioritized Stories to fill at least the first Release. Ideally, there would be enough Stories for two or three releases, so that the broad outlines of the technology and personnel needed can be understood.

Here's a possible outline for Sprint Zero:
Determine the length of sprints
Identify business value (the criteria to prioritize Stories)
Create epics. Prioritize epics (consider relative business value)
For the highest priority epic, turn the epic into stories
Prioritize the stories (consider relative business value)
For each story, create a definition of done
Create a team(s) workspace(s), and provide appropriate technology
Configure the team(s)

The following sections explain the Scrum terms needed to understand Sprint Zero work.

===User Stories===

We've been talking about ranking the features that make up the Product Backlog. In Scrum, these features are called Stories. There is an art to defining a Scrum Story, as you might imagine. Stories often take this form:

As _[User]_____, I want _[feature]_______, so that __[value]______.

An example:

* As a fabricator making a CNC Torch Table, I want complete and accurate CAD drawings, so that my efforts will result in a well-functioning machine.

Because the User is included in defining the feature, these are known as User Stories. The following video explains a good way to evaluate and improve User Stories, which are the list of features that make up the Product Backlog.

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=L_NyCczp0Fk&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.

To review the key ideas of the video:

'''Independent''' – dependencies among or between Stories need to be identified, eliminated, or tracked. An example of dependency: the training video for making a machine cannot be made until the machine is designed.
'''Negotiable''' – the Product Owner and the Team co-create the value and attributes of features (Stories)
'''Valuable''' – all Stories are connected directly to business value.
'''Estimable''' – the Team estimates the size of the Stories relative to each other.
'''Small''' – an important concept is raised here. Stories that are coming up in priority in the first or second Release should be small enough to be finished in one Sprint. Stories that are being implemented later can be large (Epics – more on this below).
'''Testable''' – knowing how we will know the Story is done, also called knowing the Definition of Done.

This review of the qualities of a good User Story gives some idea of the work to be done during Sprint Zero, while the User Stories are created, combined in one list, and then prioritized to make up the Product Backlog.

===Epic User Stories===

During Sprint Zero, the Product Owner will create a list of Epics. Epics are very large Stories. An example:
* As OSE, I want complete training materials in English for the 50 tools in GVCS on DVD, so that anyone with moderate experience in fabrication, and with access to the necessary tools and materials, can fabricate any of the 50 tools.

The list of Epics doesn't have to be exhaustive, but it should be thoroughly discussed and described, using the criteria for Stories developed in the video above.

===Definition of Done===

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=9FnZsaRujpw&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
NOTE -- this video is LOUD!

Review of the main concepts of the video:

This video is from Agile; Scrum is one form of Agile. So in this video you don't see mention of a Scrum Master. Instead they talk about a Team Lead. However, the content on Definition of Done is relevant for OSE.

In this video he is discussing creating the Definition of Done at the Team level. The Product Owner needs to first supply the Team with an initial Definition of Done feature by feature. The Product Owner's Definition of Done revolves around the What (and explains the Why). The Team's Definition of Done defines the How.

One value of this video is that it stresses how all members of a multi-functional Team get involved in creating the Definition of Done. It is crucial that this Definition is agreed to by everyone on the Team. When the Team commits to the work included in a Release, and in each Sprint, they are doing so based on the agreed on Definition of Done for each Story.

There is quite a bit of excess jargon in this video, but have patience, and relate it to GVCS. For example, we not only need to have the machine design "done," but also CAD drawings, an instructional video, and many other instructional components. Unifying the release and "done-ness" of all of these is what seems like the best, and most radical!, contribution Scrum can make to GVCS. These underlying points of “What is Done?” are crucial for us to understand the work that is needed in Sprint Zero.

==OSE [[GVCS]] Scrum==

OSE already has many of the pieces necessary to Scrum. There has been a lot of thought put into how to maximize the value of the project, the resulting list of GVCS machines, and the step-by-step process needed make them. All the work that has already been done would be used as the ground work for a [[#Sprint ZERO]].

The main question seems to be, who would do the work of Sprint Zero for OSE. It seems that [[Marcin Jakubowski|Marcin]] needs to be centrally involved in the first three steps of Sprint Zero. In addition to Marcin for those first three steps, at minimum a Scrum Master would be needed. This is when the input Marcin brought back from TED in March (redistributing economic justice?) will be integrated into the current vision.

For the next two steps, turning the highest priority Epic into Stories, and prioritizing the Stories, another person(s) could step in for Marcin, if that seems best for OSE.

The need for Subject Matter Experts arises in the next step, creating the initial Definition of Done for each Story. An example of this would be creating standards for instructional videos, and ways to objectively measure if the instructional video for a certain machine meets those standards.

The real creative work needed to get ready for OSE Scrum involves understanding the incremental Releases, in other words, getting a vision of the order in which OSE "products" (the plans and documentation for each machine) will appear in the Product Backlog. The current list of [[GVCS Development Template#Process|31 steps]] needs to be reconfigured into Stories, and understood in terms of interim products that can be brought to the state of Done. The dependencies among the steps need to be charted out. This process will be used over and over, so getting it well understood, with really clear Definitions of Done, will help tremendously. The order in which the Stories from the 31 Steps appear will be a combination of the chronological dependencies of the steps, and the relative value of the Stories.

==See Also==

* [http://www.scrumhw.org/ Scrum for Hardware Product Development] ''Bringing Scrum to the Hardware Product Development Community''
* [http://maccherone.com/larry/2010/02/23/top-10-questions-when-using-agile-on-hardware-projects/ Top 10 questions when using Agile on hardware projects]

[[Category:Project Management]]

Scrum

2012-03-05T23:35:33Z

Mia Van Meter: /* OSE GVCS Scrum */

Definition: '''[[wikipedia:Scrum (development)|Scrum]]''' is an iterative and incremental methodology for software projects and product- or application-development. It is also one of the variants of [[wikipedia:agile software development|agile software development]] methodologies.

==Why would a development team use Scrum?==

As demonstrated by high-powered software teams around the world, the Scrum process can increase a development team's efficiency dramatically. In recent years, some Scrum coaches (Scrum Masters) can consistently get development teams to be six times more efficient, and it is becoming almost unremarkable for a Scrum Master to kick a team into a productive state 15 times more productive than in their pre-Scrum days.

Scrum is essentially a double handful of rules for how a team should work together, and how they should be managed. Underneath those rules is a profound understanding of human nature. What motivates us? That is the essential question which Scrum answers. Scrum rules are designed to instill ownership, motivation, and creative problem-solving in team members. The dramatic results of a well-functioning Scrum team come from the synchronistic multiplying effect of a group of developers working “in the flow.” [http://en.wikipedia.org/wiki/Jeff_Sutherland/ Jeff Sutherland], one of the creators of Scrum, refers to these as “activated” teams.

Following [http://en.wikipedia.org/wiki/Lean_software_development/ Lean] development principles, the rules of Scrum are stripped down to the essentials. One of the implications of this is that teams must adopt all the Scrum rules in order to get Scrum results. Jeff Sutherland's favorite lecture topic seems to be “Scrumbutt.” This occurs when teams say, “Yes, we're doing Scrum, but...” and explain an aspect of Scrum they decided not to implement. According to Sutherland, you cannot get dramatic results unless you are pretty much a Scrum purist. That said, Scrum can “wrap around” other software development process technologies like, for example, XP or Lean. It's not essential to understand those technologies fully, for our purposes, but they are mentioned in the discussion on this page.

The most relevant question for a project like OSE is – is Scrum applicable outside the software development world? This is the answer that Joe Justice and the WikiSpeed team answer with a resounding “Yes!” In the 10-minute TEDX talk below, he explains briefly how the WikiSpeed Team, a collection of 44 volunteers in 4 countries, in three months used Scrum and associated processes to design and build a road-certifiable 4-person commuter car that can get over 100 miles per gallon in standard EPA road tests. The relevance of this to OSE is obvious – a distributed team of volunteers co-developing revolutionary hardware, sound familiar? It's well worth your while to spend a few hours absorbing the information on Scrum that this page points to, and to help explore its relevance for OSE in general, and the GVCS in particular.

In this video, Joe Justice, of WikiSpeed, explains the process his all-volunteer design team used to exceed expectations in their fuel-efficient car design.

<html><iframe width="300" height="182" src="http://www.youtube.com/watch?v=x8jdx-lf2Dw" frameborder="0" allowfullscreen></iframe></html>

.
.

.
.

==What is Scrum?==

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/watch?v=Q5k7a9YEoUI" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
The video above is a great first introduction to Scrum! It's fast paced, and the graphics easily convey the important information.

Of course, like any single Scrum coach, this one has his own take on Scrum, and in some instances it's likely that OSE Scrum will be different.

To review his core concepts:

Roles: Product Owner, Scrum Master, Team Members (developers, testers, customers)

Release Planning:
*Product Backlog– Estimate for each feature wanted in product.
*Release Backlog
*plan 4-12 Sprints – a substantive back log to a ship-ready state
*Sprint Backlog

Burndown Chart – day by day measure of the amount of work left in a Release, or Sprint

Bugs – have a separate Defect Backlog. Resolve bugs within the Sprint.

Daily Scrum – short, standing, identify bugs.

So that video is a great introduction to Scrum, but how would we actually get started?

The Scrum process starts with the Product Owner. They are responsible for creating the Product Backlog, creating the Development Team, and for providing the Team with the tools necessary for them to work. The Scrum Master helps the Product Owner with these tasks.

===Sprint ZERO===

To get ready for the first development Sprint, the Product Owner and the Scrum Master need to meet together, and with the Team, and do some initial preparation. The amount of time spent on Sprint Zero should be limited, and agreed upon in advance. Unfinished preparation can be added to the Product Backlog when Sprint Zero is finished. Additionally, the task of adding to the Product Backlog, and refining features that are down the road a bit, will be ongoing tasks for the Product Owner.

The most important outcome of Sprint Zero is to create understanding about the value of the work. Given that OSE might choose to have a team (Scrum) of Product Owners, it could make implementation more clear if the business values we are creating are explicitly ranked. Usually the process of identifying and clarifying the business value is held more distantly from the Team. In the case of OSE, it seems likely that a group of people will be determining the relative priorities of our business values, and the relative rankings of the features that we're planning on creating.

Here are some further questions to be taken up during Sprint Zero:
* Do we have the right people with the right skills? Is there a need for consultants, etc.?

* Given the Epic User Stories, the values, and the efinitions of done, what sort of work place, tools and technology set up are indicated?

* What is the general approach we are taking? What will be the length of our Sprints? What is the Road Map -- the key release points? How many teams will there be? If there are multiple teams, how will the Scrum Masters and the Product Owners from the multiple teams work together?

At the end of Sprint Zero, the Product Backlog must contain enough prioritized Stories to fill at least the first Release. Ideally, there would be enough Stories for two or three releases, so that the broad outlines of the technology and personnel needed can be understood.

Here's a possible outline for Sprint Zero:
Determine the length of sprints
Identify business value (the criteria to prioritize Stories)
Create epics. Prioritize epics (consider relative business value)
For the highest priority epic, turn the epic into stories
Prioritize the stories (consider relative business value)
For each story, create a definition of done
Create a team(s) workspace(s), and provide appropriate technology
Configure the team(s)

The following sections explain the Scrum terms needed to understand Sprint Zero work.

===User Stories===

We've been talking about ranking the features that make up the Product Backlog. In Scrum, these features are called Stories. There is an art to defining a Scrum Story, as you might imagine. Stories often take this form:

As _[User]_____, I want _[feature]_______, so that __[value]______.

An example:

* As a fabricator making a CNC Torch Table, I want complete and accurate CAD drawings, so that my efforts will result in a well-functioning machine.

Because the User is included in defining the feature, these are known as User Stories. The following video explains a good way to evaluate and improve User Stories, which are the list of features that make up the Product Backlog.

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=L_NyCczp0Fk&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.

To review the key ideas of the video:

'''Independent''' – dependencies among or between Stories need to be identified, eliminated, or tracked. An example of dependency: the training video for making a machine cannot be made until the machine is designed.
'''Negotiable''' – the Product Owner and the Team co-create the value and attributes of features (Stories)
'''Valuable''' – all Stories are connected directly to business value.
'''Estimable''' – the Team estimates the size of the Stories relative to each other.
'''Small''' – an important concept is raised here. Stories that are coming up in priority in the first or second Release should be small enough to be finished in one Sprint. Stories that are being implemented later can be large (Epics – more on this below).
'''Testable''' – knowing how we will know the Story is done, also called knowing the Definition of Done.

This review of the qualities of a good User Story gives some idea of the work to be done during Sprint Zero, while the User Stories are created, combined in one list, and then prioritized to make up the Product Backlog.

===Epic User Stories===

During Sprint Zero, the Product Owner will create a list of Epics. Epics are very large Stories. An example:
* As OSE, I want complete training materials in English for the 50 tools in GVCS on DVD, so that anyone with moderate experience in fabrication, and with access to the necessary tools and materials, can fabricate any of the 50 tools.

The list of Epics doesn't have to be exhaustive, but it should be thoroughly discussed and described, using the criteria for Stories developed in the video above.

===Definition of Done===

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=9FnZsaRujpw&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
NOTE -- this video is LOUD!

Review of the main concepts of the video:

This video is from Agile; Scrum is one form of Agile. So in this video you don't see mention of a Scrum Master. Instead they talk about a Team Lead. However, the content on Definition of Done is relevant for OSE.

In this video he is discussing creating the Definition of Done at the Team level. The Product Owner needs to first supply the Team with an initial Definition of Done feature by feature. The Product Owner's Definition of Done revolves around the What (and explains the Why). The Team's Definition of Done defines the How.

One value of this video is that it stresses how all members of a multi-functional Team get involved in creating the Definition of Done. It is crucial that this Definition is agreed to by everyone on the Team. When the Team commits to the work included in a Release, and in each Sprint, they are doing so based on the agreed on Definition of Done for each Story.

There is quite a bit of excess jargon in this video, but have patience, and relate it to GVCS. For example, we not only need to have the machine design "done," but also CAD drawings, an instructional video, and many other instructional components. Unifying the release and "done-ness" of all of these is what seems like the best, and most radical!, contribution Scrum can make to GVCS. These underlying points of “What is Done?” are crucial for us to understand the work that is needed in Sprint Zero.

==OSE [[GVCS]] Scrum==

OSE already has many of the pieces necessary to Scrum. There has been a lot of thought put into how to maximize the value of the project, the resulting list of GVCS machines, and the step-by-step process needed make them. All the work that has already been done would be used as the ground work for a [[#Sprint ZERO]].

The main question seems to be, who would do the work of Sprint Zero for OSE. It seems that [[Marcin Jakubowski|Marcin]] needs to be centrally involved in the first three steps of Sprint Zero. In addition to Marcin for those first three steps, at minimum a Scrum Master would be needed.

For the next two steps, turning the highest priority Epic into Stories, and prioritizing the Stories, another person(s) could step in for Marcin, if that seems best for OSE.

The need for Subject Matter Experts arises in the next step, creating the initial Definition of Done for each Story. An example of this would be creating standards for instructional videos, and ways to objectively measure if the instructional video for a certain machine meets those standards.

The real creative work needed to get ready for OSE Scrum involves understanding the incremental Releases, in other words, getting a vision of the order in which OSE "products" (the plans and documentation for each machine) will appear in the Product Backlog. The current list of [[GVCS Development Template#Process|31 steps]] needs to be reconfigured into Stories, and understood in terms of interim products that can be brought to the state of Done. The dependencies among the steps need to be charted out. This process will be used over and over, so getting it well understood, with really clear Definitions of Done, will help tremendously. The order in which the Stories from the 31 Steps appear will be a combination of the chronological dependencies of the steps, and the relative value of the Stories.

==See Also==

* [http://www.scrumhw.org/ Scrum for Hardware Product Development] ''Bringing Scrum to the Hardware Product Development Community''
* [http://maccherone.com/larry/2010/02/23/top-10-questions-when-using-agile-on-hardware-projects/ Top 10 questions when using Agile on hardware projects]

[[Category:Project Management]]

Scrum

2012-03-05T23:34:57Z

Mia Van Meter: /* OSE GVCS Scrum */

Definition: '''[[wikipedia:Scrum (development)|Scrum]]''' is an iterative and incremental methodology for software projects and product- or application-development. It is also one of the variants of [[wikipedia:agile software development|agile software development]] methodologies.

==Why would a development team use Scrum?==

As demonstrated by high-powered software teams around the world, the Scrum process can increase a development team's efficiency dramatically. In recent years, some Scrum coaches (Scrum Masters) can consistently get development teams to be six times more efficient, and it is becoming almost unremarkable for a Scrum Master to kick a team into a productive state 15 times more productive than in their pre-Scrum days.

Scrum is essentially a double handful of rules for how a team should work together, and how they should be managed. Underneath those rules is a profound understanding of human nature. What motivates us? That is the essential question which Scrum answers. Scrum rules are designed to instill ownership, motivation, and creative problem-solving in team members. The dramatic results of a well-functioning Scrum team come from the synchronistic multiplying effect of a group of developers working “in the flow.” [http://en.wikipedia.org/wiki/Jeff_Sutherland/ Jeff Sutherland], one of the creators of Scrum, refers to these as “activated” teams.

Following [http://en.wikipedia.org/wiki/Lean_software_development/ Lean] development principles, the rules of Scrum are stripped down to the essentials. One of the implications of this is that teams must adopt all the Scrum rules in order to get Scrum results. Jeff Sutherland's favorite lecture topic seems to be “Scrumbutt.” This occurs when teams say, “Yes, we're doing Scrum, but...” and explain an aspect of Scrum they decided not to implement. According to Sutherland, you cannot get dramatic results unless you are pretty much a Scrum purist. That said, Scrum can “wrap around” other software development process technologies like, for example, XP or Lean. It's not essential to understand those technologies fully, for our purposes, but they are mentioned in the discussion on this page.

The most relevant question for a project like OSE is – is Scrum applicable outside the software development world? This is the answer that Joe Justice and the WikiSpeed team answer with a resounding “Yes!” In the 10-minute TEDX talk below, he explains briefly how the WikiSpeed Team, a collection of 44 volunteers in 4 countries, in three months used Scrum and associated processes to design and build a road-certifiable 4-person commuter car that can get over 100 miles per gallon in standard EPA road tests. The relevance of this to OSE is obvious – a distributed team of volunteers co-developing revolutionary hardware, sound familiar? It's well worth your while to spend a few hours absorbing the information on Scrum that this page points to, and to help explore its relevance for OSE in general, and the GVCS in particular.

In this video, Joe Justice, of WikiSpeed, explains the process his all-volunteer design team used to exceed expectations in their fuel-efficient car design.

<html><iframe width="300" height="182" src="http://www.youtube.com/watch?v=x8jdx-lf2Dw" frameborder="0" allowfullscreen></iframe></html>

.
.

.
.

==What is Scrum?==

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/watch?v=Q5k7a9YEoUI" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
The video above is a great first introduction to Scrum! It's fast paced, and the graphics easily convey the important information.

Of course, like any single Scrum coach, this one has his own take on Scrum, and in some instances it's likely that OSE Scrum will be different.

To review his core concepts:

Roles: Product Owner, Scrum Master, Team Members (developers, testers, customers)

Release Planning:
*Product Backlog– Estimate for each feature wanted in product.
*Release Backlog
*plan 4-12 Sprints – a substantive back log to a ship-ready state
*Sprint Backlog

Burndown Chart – day by day measure of the amount of work left in a Release, or Sprint

Bugs – have a separate Defect Backlog. Resolve bugs within the Sprint.

Daily Scrum – short, standing, identify bugs.

So that video is a great introduction to Scrum, but how would we actually get started?

The Scrum process starts with the Product Owner. They are responsible for creating the Product Backlog, creating the Development Team, and for providing the Team with the tools necessary for them to work. The Scrum Master helps the Product Owner with these tasks.

===Sprint ZERO===

To get ready for the first development Sprint, the Product Owner and the Scrum Master need to meet together, and with the Team, and do some initial preparation. The amount of time spent on Sprint Zero should be limited, and agreed upon in advance. Unfinished preparation can be added to the Product Backlog when Sprint Zero is finished. Additionally, the task of adding to the Product Backlog, and refining features that are down the road a bit, will be ongoing tasks for the Product Owner.

The most important outcome of Sprint Zero is to create understanding about the value of the work. Given that OSE might choose to have a team (Scrum) of Product Owners, it could make implementation more clear if the business values we are creating are explicitly ranked. Usually the process of identifying and clarifying the business value is held more distantly from the Team. In the case of OSE, it seems likely that a group of people will be determining the relative priorities of our business values, and the relative rankings of the features that we're planning on creating.

Here are some further questions to be taken up during Sprint Zero:
* Do we have the right people with the right skills? Is there a need for consultants, etc.?

* Given the Epic User Stories, the values, and the efinitions of done, what sort of work place, tools and technology set up are indicated?

* What is the general approach we are taking? What will be the length of our Sprints? What is the Road Map -- the key release points? How many teams will there be? If there are multiple teams, how will the Scrum Masters and the Product Owners from the multiple teams work together?

At the end of Sprint Zero, the Product Backlog must contain enough prioritized Stories to fill at least the first Release. Ideally, there would be enough Stories for two or three releases, so that the broad outlines of the technology and personnel needed can be understood.

Here's a possible outline for Sprint Zero:
Determine the length of sprints
Identify business value (the criteria to prioritize Stories)
Create epics. Prioritize epics (consider relative business value)
For the highest priority epic, turn the epic into stories
Prioritize the stories (consider relative business value)
For each story, create a definition of done
Create a team(s) workspace(s), and provide appropriate technology
Configure the team(s)

The following sections explain the Scrum terms needed to understand Sprint Zero work.

===User Stories===

We've been talking about ranking the features that make up the Product Backlog. In Scrum, these features are called Stories. There is an art to defining a Scrum Story, as you might imagine. Stories often take this form:

As _[User]_____, I want _[feature]_______, so that __[value]______.

An example:

* As a fabricator making a CNC Torch Table, I want complete and accurate CAD drawings, so that my efforts will result in a well-functioning machine.

Because the User is included in defining the feature, these are known as User Stories. The following video explains a good way to evaluate and improve User Stories, which are the list of features that make up the Product Backlog.

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=L_NyCczp0Fk&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.

To review the key ideas of the video:

'''Independent''' – dependencies among or between Stories need to be identified, eliminated, or tracked. An example of dependency: the training video for making a machine cannot be made until the machine is designed.
'''Negotiable''' – the Product Owner and the Team co-create the value and attributes of features (Stories)
'''Valuable''' – all Stories are connected directly to business value.
'''Estimable''' – the Team estimates the size of the Stories relative to each other.
'''Small''' – an important concept is raised here. Stories that are coming up in priority in the first or second Release should be small enough to be finished in one Sprint. Stories that are being implemented later can be large (Epics – more on this below).
'''Testable''' – knowing how we will know the Story is done, also called knowing the Definition of Done.

This review of the qualities of a good User Story gives some idea of the work to be done during Sprint Zero, while the User Stories are created, combined in one list, and then prioritized to make up the Product Backlog.

===Epic User Stories===

During Sprint Zero, the Product Owner will create a list of Epics. Epics are very large Stories. An example:
* As OSE, I want complete training materials in English for the 50 tools in GVCS on DVD, so that anyone with moderate experience in fabrication, and with access to the necessary tools and materials, can fabricate any of the 50 tools.

The list of Epics doesn't have to be exhaustive, but it should be thoroughly discussed and described, using the criteria for Stories developed in the video above.

===Definition of Done===

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=9FnZsaRujpw&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
NOTE -- this video is LOUD!

Review of the main concepts of the video:

This video is from Agile; Scrum is one form of Agile. So in this video you don't see mention of a Scrum Master. Instead they talk about a Team Lead. However, the content on Definition of Done is relevant for OSE.

In this video he is discussing creating the Definition of Done at the Team level. The Product Owner needs to first supply the Team with an initial Definition of Done feature by feature. The Product Owner's Definition of Done revolves around the What (and explains the Why). The Team's Definition of Done defines the How.

One value of this video is that it stresses how all members of a multi-functional Team get involved in creating the Definition of Done. It is crucial that this Definition is agreed to by everyone on the Team. When the Team commits to the work included in a Release, and in each Sprint, they are doing so based on the agreed on Definition of Done for each Story.

There is quite a bit of excess jargon in this video, but have patience, and relate it to GVCS. For example, we not only need to have the machine design "done," but also CAD drawings, an instructional video, and many other instructional components. Unifying the release and "done-ness" of all of these is what seems like the best, and most radical!, contribution Scrum can make to GVCS. These underlying points of “What is Done?” are crucial for us to understand the work that is needed in Sprint Zero.

==OSE [[GVCS]] Scrum==

OSE already has many of the pieces necessary to Scrum. There has been a lot of thought put into how to maximize the value of the project, the resulting list of GVCS machines, and the step-by-step process needed make them. All the work that has already been done would be used as the ground work for a [[#Sprint ZERO]].

The main question seems to be, who would do the work of Sprint Zero for OSE. It seems that [[Marcin Jakubowski|Marcin]] needs to be centrally involved in the first three steps of Sprint Zero. In addition to Marcin for those first three steps, at minimum a Scrum Master would be needed.

For the next two steps, turning the highest priority Epic into Stories, and prioritizing the Stories, another person(s) could step in for Marcin, if that seems best for OSE.

The need for Subject Matter Experts arises in the next step, creating the initial Definition of Done for each Story. An example of this would be creating standards for instructional videos, and ways to objectively measure if the instructional video for a certain machine meets those standards.

The real creative work needed to get ready for OSE Scrum involves understanding the incremental Releases, in other words, getting a vision of the order in which OSE "products" (the plans and documentation for each machine) will appear in the Product Backlog. The current list of [[GVCS Development Templatee#Process|31 steps]] needs to be reconfigured into Stories, and understood in terms of interim products that can be brought to the state of Done. The dependencies among the steps need to be charted out. This process will be used over and over, so getting it well understood, with really clear Definitions of Done, will help tremendously. The order in which the Stories from the 31 Steps appear will be a combination of the chronological dependencies of the steps, and the relative value of the Stories.

==See Also==

* [http://www.scrumhw.org/ Scrum for Hardware Product Development] ''Bringing Scrum to the Hardware Product Development Community''
* [http://maccherone.com/larry/2010/02/23/top-10-questions-when-using-agile-on-hardware-projects/ Top 10 questions when using Agile on hardware projects]

[[Category:Project Management]]

Scrum

2012-03-05T23:34:14Z

Mia Van Meter: /* OSE GVCS Scrum */ rewrite of section

Definition: '''[[wikipedia:Scrum (development)|Scrum]]''' is an iterative and incremental methodology for software projects and product- or application-development. It is also one of the variants of [[wikipedia:agile software development|agile software development]] methodologies.

==Why would a development team use Scrum?==

As demonstrated by high-powered software teams around the world, the Scrum process can increase a development team's efficiency dramatically. In recent years, some Scrum coaches (Scrum Masters) can consistently get development teams to be six times more efficient, and it is becoming almost unremarkable for a Scrum Master to kick a team into a productive state 15 times more productive than in their pre-Scrum days.

Scrum is essentially a double handful of rules for how a team should work together, and how they should be managed. Underneath those rules is a profound understanding of human nature. What motivates us? That is the essential question which Scrum answers. Scrum rules are designed to instill ownership, motivation, and creative problem-solving in team members. The dramatic results of a well-functioning Scrum team come from the synchronistic multiplying effect of a group of developers working “in the flow.” [http://en.wikipedia.org/wiki/Jeff_Sutherland/ Jeff Sutherland], one of the creators of Scrum, refers to these as “activated” teams.

Following [http://en.wikipedia.org/wiki/Lean_software_development/ Lean] development principles, the rules of Scrum are stripped down to the essentials. One of the implications of this is that teams must adopt all the Scrum rules in order to get Scrum results. Jeff Sutherland's favorite lecture topic seems to be “Scrumbutt.” This occurs when teams say, “Yes, we're doing Scrum, but...” and explain an aspect of Scrum they decided not to implement. According to Sutherland, you cannot get dramatic results unless you are pretty much a Scrum purist. That said, Scrum can “wrap around” other software development process technologies like, for example, XP or Lean. It's not essential to understand those technologies fully, for our purposes, but they are mentioned in the discussion on this page.

The most relevant question for a project like OSE is – is Scrum applicable outside the software development world? This is the answer that Joe Justice and the WikiSpeed team answer with a resounding “Yes!” In the 10-minute TEDX talk below, he explains briefly how the WikiSpeed Team, a collection of 44 volunteers in 4 countries, in three months used Scrum and associated processes to design and build a road-certifiable 4-person commuter car that can get over 100 miles per gallon in standard EPA road tests. The relevance of this to OSE is obvious – a distributed team of volunteers co-developing revolutionary hardware, sound familiar? It's well worth your while to spend a few hours absorbing the information on Scrum that this page points to, and to help explore its relevance for OSE in general, and the GVCS in particular.

In this video, Joe Justice, of WikiSpeed, explains the process his all-volunteer design team used to exceed expectations in their fuel-efficient car design.

<html><iframe width="300" height="182" src="http://www.youtube.com/watch?v=x8jdx-lf2Dw" frameborder="0" allowfullscreen></iframe></html>

.
.

.
.

==What is Scrum?==

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/watch?v=Q5k7a9YEoUI" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
The video above is a great first introduction to Scrum! It's fast paced, and the graphics easily convey the important information.

Of course, like any single Scrum coach, this one has his own take on Scrum, and in some instances it's likely that OSE Scrum will be different.

To review his core concepts:

Roles: Product Owner, Scrum Master, Team Members (developers, testers, customers)

Release Planning:
*Product Backlog– Estimate for each feature wanted in product.
*Release Backlog
*plan 4-12 Sprints – a substantive back log to a ship-ready state
*Sprint Backlog

Burndown Chart – day by day measure of the amount of work left in a Release, or Sprint

Bugs – have a separate Defect Backlog. Resolve bugs within the Sprint.

Daily Scrum – short, standing, identify bugs.

So that video is a great introduction to Scrum, but how would we actually get started?

The Scrum process starts with the Product Owner. They are responsible for creating the Product Backlog, creating the Development Team, and for providing the Team with the tools necessary for them to work. The Scrum Master helps the Product Owner with these tasks.

===Sprint ZERO===

To get ready for the first development Sprint, the Product Owner and the Scrum Master need to meet together, and with the Team, and do some initial preparation. The amount of time spent on Sprint Zero should be limited, and agreed upon in advance. Unfinished preparation can be added to the Product Backlog when Sprint Zero is finished. Additionally, the task of adding to the Product Backlog, and refining features that are down the road a bit, will be ongoing tasks for the Product Owner.

The most important outcome of Sprint Zero is to create understanding about the value of the work. Given that OSE might choose to have a team (Scrum) of Product Owners, it could make implementation more clear if the business values we are creating are explicitly ranked. Usually the process of identifying and clarifying the business value is held more distantly from the Team. In the case of OSE, it seems likely that a group of people will be determining the relative priorities of our business values, and the relative rankings of the features that we're planning on creating.

Here are some further questions to be taken up during Sprint Zero:
* Do we have the right people with the right skills? Is there a need for consultants, etc.?

* Given the Epic User Stories, the values, and the efinitions of done, what sort of work place, tools and technology set up are indicated?

* What is the general approach we are taking? What will be the length of our Sprints? What is the Road Map -- the key release points? How many teams will there be? If there are multiple teams, how will the Scrum Masters and the Product Owners from the multiple teams work together?

At the end of Sprint Zero, the Product Backlog must contain enough prioritized Stories to fill at least the first Release. Ideally, there would be enough Stories for two or three releases, so that the broad outlines of the technology and personnel needed can be understood.

Here's a possible outline for Sprint Zero:
Determine the length of sprints
Identify business value (the criteria to prioritize Stories)
Create epics. Prioritize epics (consider relative business value)
For the highest priority epic, turn the epic into stories
Prioritize the stories (consider relative business value)
For each story, create a definition of done
Create a team(s) workspace(s), and provide appropriate technology
Configure the team(s)

The following sections explain the Scrum terms needed to understand Sprint Zero work.

===User Stories===

We've been talking about ranking the features that make up the Product Backlog. In Scrum, these features are called Stories. There is an art to defining a Scrum Story, as you might imagine. Stories often take this form:

As _[User]_____, I want _[feature]_______, so that __[value]______.

An example:

* As a fabricator making a CNC Torch Table, I want complete and accurate CAD drawings, so that my efforts will result in a well-functioning machine.

Because the User is included in defining the feature, these are known as User Stories. The following video explains a good way to evaluate and improve User Stories, which are the list of features that make up the Product Backlog.

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=L_NyCczp0Fk&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.

To review the key ideas of the video:

'''Independent''' – dependencies among or between Stories need to be identified, eliminated, or tracked. An example of dependency: the training video for making a machine cannot be made until the machine is designed.
'''Negotiable''' – the Product Owner and the Team co-create the value and attributes of features (Stories)
'''Valuable''' – all Stories are connected directly to business value.
'''Estimable''' – the Team estimates the size of the Stories relative to each other.
'''Small''' – an important concept is raised here. Stories that are coming up in priority in the first or second Release should be small enough to be finished in one Sprint. Stories that are being implemented later can be large (Epics – more on this below).
'''Testable''' – knowing how we will know the Story is done, also called knowing the Definition of Done.

This review of the qualities of a good User Story gives some idea of the work to be done during Sprint Zero, while the User Stories are created, combined in one list, and then prioritized to make up the Product Backlog.

===Epic User Stories===

During Sprint Zero, the Product Owner will create a list of Epics. Epics are very large Stories. An example:
* As OSE, I want complete training materials in English for the 50 tools in GVCS on DVD, so that anyone with moderate experience in fabrication, and with access to the necessary tools and materials, can fabricate any of the 50 tools.

The list of Epics doesn't have to be exhaustive, but it should be thoroughly discussed and described, using the criteria for Stories developed in the video above.

===Definition of Done===

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=9FnZsaRujpw&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
NOTE -- this video is LOUD!

Review of the main concepts of the video:

This video is from Agile; Scrum is one form of Agile. So in this video you don't see mention of a Scrum Master. Instead they talk about a Team Lead. However, the content on Definition of Done is relevant for OSE.

In this video he is discussing creating the Definition of Done at the Team level. The Product Owner needs to first supply the Team with an initial Definition of Done feature by feature. The Product Owner's Definition of Done revolves around the What (and explains the Why). The Team's Definition of Done defines the How.

One value of this video is that it stresses how all members of a multi-functional Team get involved in creating the Definition of Done. It is crucial that this Definition is agreed to by everyone on the Team. When the Team commits to the work included in a Release, and in each Sprint, they are doing so based on the agreed on Definition of Done for each Story.

There is quite a bit of excess jargon in this video, but have patience, and relate it to GVCS. For example, we not only need to have the machine design "done," but also CAD drawings, an instructional video, and many other instructional components. Unifying the release and "done-ness" of all of these is what seems like the best, and most radical!, contribution Scrum can make to GVCS. These underlying points of “What is Done?” are crucial for us to understand the work that is needed in Sprint Zero.

==OSE [[GVCS]] Scrum==

OSE already has many of the pieces necessary to Scrum. There has been a lot of thought put into how to maximize the value of the project, the resulting list of GVCS machines, and the step-by-step process needed make them. All the work that has already been done would be used as the ground work for a [[#Sprint ZERO]].

The main question seems to be, who would do the work of Sprint Zero for OSE. It seems that Marcin

I would think that [[Marcin Jakubowski|Marcin]] needs to be centrally involved in the first three steps of Sprint Zero. In addition to Marcin for those first three steps, at minimum a Scrum Master would be needed.

For the next two steps, turning the highest priority Epic into Stories, and prioritizing the Stories, another person(s) could step in for Marcin, if that seems best for OSE.

The need for Subject Matter Experts arises in the next step, creating the initial Definition of Done for each Story. An example of this would be creating standards for instructional videos, and ways to objectively measure if the instructional video for a certain machine meets those standards.

The real creative work needed to get ready for OSE Scrum involves understanding the incremental Releases, in other words, getting a vision of the order in which OSE "products" (the plans and documentation for each machine) will appear in the Product Backlog. The current list of [[GVCS Development Templatee#Process|31 steps]] needs to be reconfigured into Stories, and understood in terms of interim products that can be brought to the state of Done. The dependencies among the steps need to be charted out. This process will be used over and over, so getting it well understood, with really clear Definitions of Done, will help tremendously. The order in which the Stories from the 31 Steps appear will be a combination of the chronological dependencies of the steps, and the relative value of the Stories.

==See Also==

* [http://www.scrumhw.org/ Scrum for Hardware Product Development] ''Bringing Scrum to the Hardware Product Development Community''
* [http://maccherone.com/larry/2010/02/23/top-10-questions-when-using-agile-on-hardware-projects/ Top 10 questions when using Agile on hardware projects]

[[Category:Project Management]]

Scrum

2012-03-05T23:18:10Z

Mia Van Meter: /* OSE GVCS Scrum */

Definition: '''[[wikipedia:Scrum (development)|Scrum]]''' is an iterative and incremental methodology for software projects and product- or application-development. It is also one of the variants of [[wikipedia:agile software development|agile software development]] methodologies.

==Why would a development team use Scrum?==

As demonstrated by high-powered software teams around the world, the Scrum process can increase a development team's efficiency dramatically. In recent years, some Scrum coaches (Scrum Masters) can consistently get development teams to be six times more efficient, and it is becoming almost unremarkable for a Scrum Master to kick a team into a productive state 15 times more productive than in their pre-Scrum days.

Scrum is essentially a double handful of rules for how a team should work together, and how they should be managed. Underneath those rules is a profound understanding of human nature. What motivates us? That is the essential question which Scrum answers. Scrum rules are designed to instill ownership, motivation, and creative problem-solving in team members. The dramatic results of a well-functioning Scrum team come from the synchronistic multiplying effect of a group of developers working “in the flow.” [http://en.wikipedia.org/wiki/Jeff_Sutherland/ Jeff Sutherland], one of the creators of Scrum, refers to these as “activated” teams.

Following [http://en.wikipedia.org/wiki/Lean_software_development/ Lean] development principles, the rules of Scrum are stripped down to the essentials. One of the implications of this is that teams must adopt all the Scrum rules in order to get Scrum results. Jeff Sutherland's favorite lecture topic seems to be “Scrumbutt.” This occurs when teams say, “Yes, we're doing Scrum, but...” and explain an aspect of Scrum they decided not to implement. According to Sutherland, you cannot get dramatic results unless you are pretty much a Scrum purist. That said, Scrum can “wrap around” other software development process technologies like, for example, XP or Lean. It's not essential to understand those technologies fully, for our purposes, but they are mentioned in the discussion on this page.

The most relevant question for a project like OSE is – is Scrum applicable outside the software development world? This is the answer that Joe Justice and the WikiSpeed team answer with a resounding “Yes!” In the 10-minute TEDX talk below, he explains briefly how the WikiSpeed Team, a collection of 44 volunteers in 4 countries, in three months used Scrum and associated processes to design and build a road-certifiable 4-person commuter car that can get over 100 miles per gallon in standard EPA road tests. The relevance of this to OSE is obvious – a distributed team of volunteers co-developing revolutionary hardware, sound familiar? It's well worth your while to spend a few hours absorbing the information on Scrum that this page points to, and to help explore its relevance for OSE in general, and the GVCS in particular.

In this video, Joe Justice, of WikiSpeed, explains the process his all-volunteer design team used to exceed expectations in their fuel-efficient car design.

<html><iframe width="300" height="182" src="http://www.youtube.com/watch?v=x8jdx-lf2Dw" frameborder="0" allowfullscreen></iframe></html>

.
.

.
.

==What is Scrum?==

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/watch?v=Q5k7a9YEoUI" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
The video above is a great first introduction to Scrum! It's fast paced, and the graphics easily convey the important information.

Of course, like any single Scrum coach, this one has his own take on Scrum, and in some instances it's likely that OSE Scrum will be different.

To review his core concepts:

Roles: Product Owner, Scrum Master, Team Members (developers, testers, customers)

Release Planning:
*Product Backlog– Estimate for each feature wanted in product.
*Release Backlog
*plan 4-12 Sprints – a substantive back log to a ship-ready state
*Sprint Backlog

Burndown Chart – day by day measure of the amount of work left in a Release, or Sprint

Bugs – have a separate Defect Backlog. Resolve bugs within the Sprint.

Daily Scrum – short, standing, identify bugs.

So that video is a great introduction to Scrum, but how would we actually get started?

The Scrum process starts with the Product Owner. They are responsible for creating the Product Backlog, creating the Development Team, and for providing the Team with the tools necessary for them to work. The Scrum Master helps the Product Owner with these tasks.

===Sprint ZERO===

To get ready for the first development Sprint, the Product Owner and the Scrum Master need to meet together, and with the Team, and do some initial preparation. The amount of time spent on Sprint Zero should be limited, and agreed upon in advance. Unfinished preparation can be added to the Product Backlog when Sprint Zero is finished. Additionally, the task of adding to the Product Backlog, and refining features that are down the road a bit, will be ongoing tasks for the Product Owner.

The most important outcome of Sprint Zero is to create understanding about the value of the work. Given that OSE might choose to have a team (Scrum) of Product Owners, it could make implementation more clear if the business values we are creating are explicitly ranked. Usually the process of identifying and clarifying the business value is held more distantly from the Team. In the case of OSE, it seems likely that a group of people will be determining the relative priorities of our business values, and the relative rankings of the features that we're planning on creating.

Here are some further questions to be taken up during Sprint Zero:
* Do we have the right people with the right skills? Is there a need for consultants, etc.?

* Given the Epic User Stories, the values, and the efinitions of done, what sort of work place, tools and technology set up are indicated?

* What is the general approach we are taking? What will be the length of our Sprints? What is the Road Map -- the key release points? How many teams will there be? If there are multiple teams, how will the Scrum Masters and the Product Owners from the multiple teams work together?

At the end of Sprint Zero, the Product Backlog must contain enough prioritized Stories to fill at least the first Release. Ideally, there would be enough Stories for two or three releases, so that the broad outlines of the technology and personnel needed can be understood.

Here's a possible outline for Sprint Zero:
Determine the length of sprints
Identify business value (the criteria to prioritize Stories)
Create epics. Prioritize epics (consider relative business value)
For the highest priority epic, turn the epic into stories
Prioritize the stories (consider relative business value)
For each story, create a definition of done
Create a team(s) workspace(s), and provide appropriate technology
Configure the team(s)

The following sections explain the Scrum terms needed to understand Sprint Zero work.

===User Stories===

We've been talking about ranking the features that make up the Product Backlog. In Scrum, these features are called Stories. There is an art to defining a Scrum Story, as you might imagine. Stories often take this form:

As _[User]_____, I want _[feature]_______, so that __[value]______.

An example:

* As a fabricator making a CNC Torch Table, I want complete and accurate CAD drawings, so that my efforts will result in a well-functioning machine.

Because the User is included in defining the feature, these are known as User Stories. The following video explains a good way to evaluate and improve User Stories, which are the list of features that make up the Product Backlog.

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=L_NyCczp0Fk&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.

To review the key ideas of the video:

'''Independent''' – dependencies among or between Stories need to be identified, eliminated, or tracked. An example of dependency: the training video for making a machine cannot be made until the machine is designed.
'''Negotiable''' – the Product Owner and the Team co-create the value and attributes of features (Stories)
'''Valuable''' – all Stories are connected directly to business value.
'''Estimable''' – the Team estimates the size of the Stories relative to each other.
'''Small''' – an important concept is raised here. Stories that are coming up in priority in the first or second Release should be small enough to be finished in one Sprint. Stories that are being implemented later can be large (Epics – more on this below).
'''Testable''' – knowing how we will know the Story is done, also called knowing the Definition of Done.

This review of the qualities of a good User Story gives some idea of the work to be done during Sprint Zero, while the User Stories are created, combined in one list, and then prioritized to make up the Product Backlog.

===Epic User Stories===

During Sprint Zero, the Product Owner will create a list of Epics. Epics are very large Stories. An example:
* As OSE, I want complete training materials in English for the 50 tools in GVCS on DVD, so that anyone with moderate experience in fabrication, and with access to the necessary tools and materials, can fabricate any of the 50 tools.

The list of Epics doesn't have to be exhaustive, but it should be thoroughly discussed and described, using the criteria for Stories developed in the video above.

===Definition of Done===

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=9FnZsaRujpw&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
NOTE -- this video is LOUD!

Review of the main concepts of the video:

This video is from Agile; Scrum is one form of Agile. So in this video you don't see mention of a Scrum Master. Instead they talk about a Team Lead. However, the content on Definition of Done is relevant for OSE.

In this video he is discussing creating the Definition of Done at the Team level. The Product Owner needs to first supply the Team with an initial Definition of Done feature by feature. The Product Owner's Definition of Done revolves around the What (and explains the Why). The Team's Definition of Done defines the How.

One value of this video is that it stresses how all members of a multi-functional Team get involved in creating the Definition of Done. It is crucial that this Definition is agreed to by everyone on the Team. When the Team commits to the work included in a Release, and in each Sprint, they are doing so based on the agreed on Definition of Done for each Story.

There is quite a bit of excess jargon in this video, but have patience, and relate it to GVCS. For example, we not only need to have the machine design "done," but also CAD drawings, an instructional video, and many other instructional components. Unifying the release and "done-ness" of all of these is what seems like the best, and most radical!, contribution Scrum can make to GVCS. These underlying points of “What is Done?” are crucial for us to understand the work that is needed in Sprint Zero.

==OSE [[GVCS]] Scrum==

OSE already has many of the pieces necessary to Scrum. There has been a lot of thought put into how to maximize the value of the project, the resulting list of GVCS machines, and the step-by-step process needed make them. All the work that has already been done would be used as the ground work for a [[#Sprint ZERO]].

The main question seems to be, who would do the work of Sprint Zero for OSE. It seems that Marcin

I would think that [[Marcin Jakubowski|Marcin]] needs to be centrally involved in the above processes. To sort out what key people are needed, Marcin should look at this next list and see what he would like to be involved in, and what he feels he could turn over to someone else:

1) Break the Epic into Stories
a) consulting the list of prioritized business values, create the Stories that will deliver the highest priority values.
b) make sure that you create a list of stakeholders and consider all the Stories that might arise from each of them in the area of highest business value.
c) use the [Stories/ [Story]] format

Steps to take to convert OSE to Scrum:

1) Identify a Product Owner and Scrum Master
2) The Scrum Master helps the Product Owner identify the Stories and business values.
3) Decide whether to use collaborative online Scrum software (especially for the Product Backlog)
3) Decide who will participate in Sprint Zero, how long it will be, and the format.

First, we list the projects, in order of priority. See GVCS graphic on the right. Changes are: remove pyrolysis oil and [[Babington burner]] with biomass [[Pelletizer]] for fueling modern [[Steam Engine]]s. The burner is already present in the form of the [[:File:Gasifiericon.jpg|Gasifier Icon]]
[[Image:Slide1Linz7.jpg|thumb|40 [[GVCS]] technologies.]]
#CEB press - [[Full Product Release]] achieved.
#LifeTrac - on Prototype II
#Soil Pulverizer -

==See Also==

* [http://www.scrumhw.org/ Scrum for Hardware Product Development] ''Bringing Scrum to the Hardware Product Development Community''
* [http://maccherone.com/larry/2010/02/23/top-10-questions-when-using-agile-on-hardware-projects/ Top 10 questions when using Agile on hardware projects]

[[Category:Project Management]]

Scrum

2012-03-05T23:15:10Z

Mia Van Meter: /* OSE GVCS Scrum */

Definition: '''[[wikipedia:Scrum (development)|Scrum]]''' is an iterative and incremental methodology for software projects and product- or application-development. It is also one of the variants of [[wikipedia:agile software development|agile software development]] methodologies.

==Why would a development team use Scrum?==

As demonstrated by high-powered software teams around the world, the Scrum process can increase a development team's efficiency dramatically. In recent years, some Scrum coaches (Scrum Masters) can consistently get development teams to be six times more efficient, and it is becoming almost unremarkable for a Scrum Master to kick a team into a productive state 15 times more productive than in their pre-Scrum days.

Scrum is essentially a double handful of rules for how a team should work together, and how they should be managed. Underneath those rules is a profound understanding of human nature. What motivates us? That is the essential question which Scrum answers. Scrum rules are designed to instill ownership, motivation, and creative problem-solving in team members. The dramatic results of a well-functioning Scrum team come from the synchronistic multiplying effect of a group of developers working “in the flow.” [http://en.wikipedia.org/wiki/Jeff_Sutherland/ Jeff Sutherland], one of the creators of Scrum, refers to these as “activated” teams.

Following [http://en.wikipedia.org/wiki/Lean_software_development/ Lean] development principles, the rules of Scrum are stripped down to the essentials. One of the implications of this is that teams must adopt all the Scrum rules in order to get Scrum results. Jeff Sutherland's favorite lecture topic seems to be “Scrumbutt.” This occurs when teams say, “Yes, we're doing Scrum, but...” and explain an aspect of Scrum they decided not to implement. According to Sutherland, you cannot get dramatic results unless you are pretty much a Scrum purist. That said, Scrum can “wrap around” other software development process technologies like, for example, XP or Lean. It's not essential to understand those technologies fully, for our purposes, but they are mentioned in the discussion on this page.

The most relevant question for a project like OSE is – is Scrum applicable outside the software development world? This is the answer that Joe Justice and the WikiSpeed team answer with a resounding “Yes!” In the 10-minute TEDX talk below, he explains briefly how the WikiSpeed Team, a collection of 44 volunteers in 4 countries, in three months used Scrum and associated processes to design and build a road-certifiable 4-person commuter car that can get over 100 miles per gallon in standard EPA road tests. The relevance of this to OSE is obvious – a distributed team of volunteers co-developing revolutionary hardware, sound familiar? It's well worth your while to spend a few hours absorbing the information on Scrum that this page points to, and to help explore its relevance for OSE in general, and the GVCS in particular.

In this video, Joe Justice, of WikiSpeed, explains the process his all-volunteer design team used to exceed expectations in their fuel-efficient car design.

<html><iframe width="300" height="182" src="http://www.youtube.com/watch?v=x8jdx-lf2Dw" frameborder="0" allowfullscreen></iframe></html>

.
.

.
.

==What is Scrum?==

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/watch?v=Q5k7a9YEoUI" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
The video above is a great first introduction to Scrum! It's fast paced, and the graphics easily convey the important information.

Of course, like any single Scrum coach, this one has his own take on Scrum, and in some instances it's likely that OSE Scrum will be different.

To review his core concepts:

Roles: Product Owner, Scrum Master, Team Members (developers, testers, customers)

Release Planning:
*Product Backlog– Estimate for each feature wanted in product.
*Release Backlog
*plan 4-12 Sprints – a substantive back log to a ship-ready state
*Sprint Backlog

Burndown Chart – day by day measure of the amount of work left in a Release, or Sprint

Bugs – have a separate Defect Backlog. Resolve bugs within the Sprint.

Daily Scrum – short, standing, identify bugs.

So that video is a great introduction to Scrum, but how would we actually get started?

The Scrum process starts with the Product Owner. They are responsible for creating the Product Backlog, creating the Development Team, and for providing the Team with the tools necessary for them to work. The Scrum Master helps the Product Owner with these tasks.

===Sprint ZERO===

To get ready for the first development Sprint, the Product Owner and the Scrum Master need to meet together, and with the Team, and do some initial preparation. The amount of time spent on Sprint Zero should be limited, and agreed upon in advance. Unfinished preparation can be added to the Product Backlog when Sprint Zero is finished. Additionally, the task of adding to the Product Backlog, and refining features that are down the road a bit, will be ongoing tasks for the Product Owner.

The most important outcome of Sprint Zero is to create understanding about the value of the work. Given that OSE might choose to have a team (Scrum) of Product Owners, it could make implementation more clear if the business values we are creating are explicitly ranked. Usually the process of identifying and clarifying the business value is held more distantly from the Team. In the case of OSE, it seems likely that a group of people will be determining the relative priorities of our business values, and the relative rankings of the features that we're planning on creating.

Here are some further questions to be taken up during Sprint Zero:
* Do we have the right people with the right skills? Is there a need for consultants, etc.?

* Given the Epic User Stories, the values, and the efinitions of done, what sort of work place, tools and technology set up are indicated?

* What is the general approach we are taking? What will be the length of our Sprints? What is the Road Map -- the key release points? How many teams will there be? If there are multiple teams, how will the Scrum Masters and the Product Owners from the multiple teams work together?

At the end of Sprint Zero, the Product Backlog must contain enough prioritized Stories to fill at least the first Release. Ideally, there would be enough Stories for two or three releases, so that the broad outlines of the technology and personnel needed can be understood.

Here's a possible outline for Sprint Zero:
Determine the length of sprints
Identify business value (the criteria to prioritize Stories)
Create epics. Prioritize epics (consider relative business value)
For the highest priority epic, turn the epic into stories
Prioritize the stories (consider relative business value)
For each story, create a definition of done
Create a team(s) workspace(s), and provide appropriate technology
Configure the team(s)

The following sections explain the Scrum terms needed to understand Sprint Zero work.

===User Stories===

We've been talking about ranking the features that make up the Product Backlog. In Scrum, these features are called Stories. There is an art to defining a Scrum Story, as you might imagine. Stories often take this form:

As _[User]_____, I want _[feature]_______, so that __[value]______.

An example:

* As a fabricator making a CNC Torch Table, I want complete and accurate CAD drawings, so that my efforts will result in a well-functioning machine.

Because the User is included in defining the feature, these are known as User Stories. The following video explains a good way to evaluate and improve User Stories, which are the list of features that make up the Product Backlog.

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=L_NyCczp0Fk&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.

To review the key ideas of the video:

'''Independent''' – dependencies among or between Stories need to be identified, eliminated, or tracked. An example of dependency: the training video for making a machine cannot be made until the machine is designed.
'''Negotiable''' – the Product Owner and the Team co-create the value and attributes of features (Stories)
'''Valuable''' – all Stories are connected directly to business value.
'''Estimable''' – the Team estimates the size of the Stories relative to each other.
'''Small''' – an important concept is raised here. Stories that are coming up in priority in the first or second Release should be small enough to be finished in one Sprint. Stories that are being implemented later can be large (Epics – more on this below).
'''Testable''' – knowing how we will know the Story is done, also called knowing the Definition of Done.

This review of the qualities of a good User Story gives some idea of the work to be done during Sprint Zero, while the User Stories are created, combined in one list, and then prioritized to make up the Product Backlog.

===Epic User Stories===

During Sprint Zero, the Product Owner will create a list of Epics. Epics are very large Stories. An example:
* As OSE, I want complete training materials in English for the 50 tools in GVCS on DVD, so that anyone with moderate experience in fabrication, and with access to the necessary tools and materials, can fabricate any of the 50 tools.

The list of Epics doesn't have to be exhaustive, but it should be thoroughly discussed and described, using the criteria for Stories developed in the video above.

===Definition of Done===

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=9FnZsaRujpw&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
NOTE -- this video is LOUD!

Review of the main concepts of the video:

This video is from Agile; Scrum is one form of Agile. So in this video you don't see mention of a Scrum Master. Instead they talk about a Team Lead. However, the content on Definition of Done is relevant for OSE.

In this video he is discussing creating the Definition of Done at the Team level. The Product Owner needs to first supply the Team with an initial Definition of Done feature by feature. The Product Owner's Definition of Done revolves around the What (and explains the Why). The Team's Definition of Done defines the How.

One value of this video is that it stresses how all members of a multi-functional Team get involved in creating the Definition of Done. It is crucial that this Definition is agreed to by everyone on the Team. When the Team commits to the work included in a Release, and in each Sprint, they are doing so based on the agreed on Definition of Done for each Story.

There is quite a bit of excess jargon in this video, but have patience, and relate it to GVCS. For example, we not only need to have the machine design "done," but also CAD drawings, an instructional video, and many other instructional components. Unifying the release and "done-ness" of all of these is what seems like the best, and most radical!, contribution Scrum can make to GVCS. These underlying points of “What is Done?” are crucial for us to understand the work that is needed in Sprint Zero.

==OSE [[GVCS]] Scrum==

OSE already has many of the pieces necessary to Scrum. There has been a lot of thought put into how to maximize the value of the project, the resulting list of GVCS machines, and the step-by-step process needed make them. All the work that has already been done would be used as the ground work for a [[#Sprint ZERO]].

To get that work into Scrum-ready state requires:
1) describe the project outcomes on a large scale
a) in Scrum terms, this means creating a list of Epics. Epics should not have dependencies with each other.
2) prioritize the "business values"
3) prioritize the Epics, after charting out which business values they deliver
4) estimate the size of the first two Releases (probably 4 months)
5) moving down the list of Epics by priority, determine how many will fit in the first two Releases (likely just the first Epic)

I would think that Marcin needs to be centrally involved in the above processes. To sort out what key people are needed, Marcin should look at this next list and see what he would like to be involved in, and what he feels he could turn over to someone else:

1) Break the Epic into Stories
a) consulting the list of prioritized business values, create the Stories that will deliver the highest priority values.
b) make sure that you create a list of stakeholders and consider all the Stories that might arise from each of them in the area of highest business value.
c) use the [Stories/ [Story]] format

Steps to take to convert OSE to Scrum:

1) Identify a Product Owner and Scrum Master
2) The Scrum Master helps the Product Owner identify the Stories and business values.
3) Decide whether to use collaborative online Scrum software (especially for the Product Backlog)
3) Decide who will participate in Sprint Zero, how long it will be, and the format.

First, we list the projects, in order of priority. See GVCS graphic on the right. Changes are: remove pyrolysis oil and [[Babington burner]] with biomass [[Pelletizer]] for fueling modern [[Steam Engine]]s. The burner is already present in the form of the [[:File:Gasifiericon.jpg|Gasifier Icon]]
[[Image:Slide1Linz7.jpg|thumb|40 [[GVCS]] technologies.]]
#CEB press - [[Full Product Release]] achieved.
#LifeTrac - on Prototype II
#Soil Pulverizer -

==See Also==

* [http://www.scrumhw.org/ Scrum for Hardware Product Development] ''Bringing Scrum to the Hardware Product Development Community''
* [http://maccherone.com/larry/2010/02/23/top-10-questions-when-using-agile-on-hardware-projects/ Top 10 questions when using Agile on hardware projects]

[[Category:Project Management]]

Scrum

2012-03-05T23:09:07Z

Mia Van Meter: /* Sprint ZERO */

Definition: '''[[wikipedia:Scrum (development)|Scrum]]''' is an iterative and incremental methodology for software projects and product- or application-development. It is also one of the variants of [[wikipedia:agile software development|agile software development]] methodologies.

==Why would a development team use Scrum?==

As demonstrated by high-powered software teams around the world, the Scrum process can increase a development team's efficiency dramatically. In recent years, some Scrum coaches (Scrum Masters) can consistently get development teams to be six times more efficient, and it is becoming almost unremarkable for a Scrum Master to kick a team into a productive state 15 times more productive than in their pre-Scrum days.

Scrum is essentially a double handful of rules for how a team should work together, and how they should be managed. Underneath those rules is a profound understanding of human nature. What motivates us? That is the essential question which Scrum answers. Scrum rules are designed to instill ownership, motivation, and creative problem-solving in team members. The dramatic results of a well-functioning Scrum team come from the synchronistic multiplying effect of a group of developers working “in the flow.” [http://en.wikipedia.org/wiki/Jeff_Sutherland/ Jeff Sutherland], one of the creators of Scrum, refers to these as “activated” teams.

Following [http://en.wikipedia.org/wiki/Lean_software_development/ Lean] development principles, the rules of Scrum are stripped down to the essentials. One of the implications of this is that teams must adopt all the Scrum rules in order to get Scrum results. Jeff Sutherland's favorite lecture topic seems to be “Scrumbutt.” This occurs when teams say, “Yes, we're doing Scrum, but...” and explain an aspect of Scrum they decided not to implement. According to Sutherland, you cannot get dramatic results unless you are pretty much a Scrum purist. That said, Scrum can “wrap around” other software development process technologies like, for example, XP or Lean. It's not essential to understand those technologies fully, for our purposes, but they are mentioned in the discussion on this page.

The most relevant question for a project like OSE is – is Scrum applicable outside the software development world? This is the answer that Joe Justice and the WikiSpeed team answer with a resounding “Yes!” In the 10-minute TEDX talk below, he explains briefly how the WikiSpeed Team, a collection of 44 volunteers in 4 countries, in three months used Scrum and associated processes to design and build a road-certifiable 4-person commuter car that can get over 100 miles per gallon in standard EPA road tests. The relevance of this to OSE is obvious – a distributed team of volunteers co-developing revolutionary hardware, sound familiar? It's well worth your while to spend a few hours absorbing the information on Scrum that this page points to, and to help explore its relevance for OSE in general, and the GVCS in particular.

In this video, Joe Justice, of WikiSpeed, explains the process his all-volunteer design team used to exceed expectations in their fuel-efficient car design.

<html><iframe width="300" height="182" src="http://www.youtube.com/watch?v=x8jdx-lf2Dw" frameborder="0" allowfullscreen></iframe></html>

.
.

.
.

==What is Scrum?==

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/watch?v=Q5k7a9YEoUI" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
The video above is a great first introduction to Scrum! It's fast paced, and the graphics easily convey the important information.

Of course, like any single Scrum coach, this one has his own take on Scrum, and in some instances it's likely that OSE Scrum will be different.

To review his core concepts:

Roles: Product Owner, Scrum Master, Team Members (developers, testers, customers)

Release Planning:
*Product Backlog– Estimate for each feature wanted in product.
*Release Backlog
*plan 4-12 Sprints – a substantive back log to a ship-ready state
*Sprint Backlog

Burndown Chart – day by day measure of the amount of work left in a Release, or Sprint

Bugs – have a separate Defect Backlog. Resolve bugs within the Sprint.

Daily Scrum – short, standing, identify bugs.

So that video is a great introduction to Scrum, but how would we actually get started?

The Scrum process starts with the Product Owner. They are responsible for creating the Product Backlog, creating the Development Team, and for providing the Team with the tools necessary for them to work. The Scrum Master helps the Product Owner with these tasks.

===Sprint ZERO===

To get ready for the first development Sprint, the Product Owner and the Scrum Master need to meet together, and with the Team, and do some initial preparation. The amount of time spent on Sprint Zero should be limited, and agreed upon in advance. Unfinished preparation can be added to the Product Backlog when Sprint Zero is finished. Additionally, the task of adding to the Product Backlog, and refining features that are down the road a bit, will be ongoing tasks for the Product Owner.

The most important outcome of Sprint Zero is to create understanding about the value of the work. Given that OSE might choose to have a team (Scrum) of Product Owners, it could make implementation more clear if the business values we are creating are explicitly ranked. Usually the process of identifying and clarifying the business value is held more distantly from the Team. In the case of OSE, it seems likely that a group of people will be determining the relative priorities of our business values, and the relative rankings of the features that we're planning on creating.

Here are some further questions to be taken up during Sprint Zero:
* Do we have the right people with the right skills? Is there a need for consultants, etc.?

* Given the Epic User Stories, the values, and the efinitions of done, what sort of work place, tools and technology set up are indicated?

* What is the general approach we are taking? What will be the length of our Sprints? What is the Road Map -- the key release points? How many teams will there be? If there are multiple teams, how will the Scrum Masters and the Product Owners from the multiple teams work together?

At the end of Sprint Zero, the Product Backlog must contain enough prioritized Stories to fill at least the first Release. Ideally, there would be enough Stories for two or three releases, so that the broad outlines of the technology and personnel needed can be understood.

Here's a possible outline for Sprint Zero:
Determine the length of sprints
Identify business value (the criteria to prioritize Stories)
Create epics. Prioritize epics (consider relative business value)
For the highest priority epic, turn the epic into stories
Prioritize the stories (consider relative business value)
For each story, create a definition of done
Create a team(s) workspace(s), and provide appropriate technology
Configure the team(s)

The following sections explain the Scrum terms needed to understand Sprint Zero work.

===User Stories===

We've been talking about ranking the features that make up the Product Backlog. In Scrum, these features are called Stories. There is an art to defining a Scrum Story, as you might imagine. Stories often take this form:

As _[User]_____, I want _[feature]_______, so that __[value]______.

An example:

* As a fabricator making a CNC Torch Table, I want complete and accurate CAD drawings, so that my efforts will result in a well-functioning machine.

Because the User is included in defining the feature, these are known as User Stories. The following video explains a good way to evaluate and improve User Stories, which are the list of features that make up the Product Backlog.

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=L_NyCczp0Fk&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.

To review the key ideas of the video:

'''Independent''' – dependencies among or between Stories need to be identified, eliminated, or tracked. An example of dependency: the training video for making a machine cannot be made until the machine is designed.
'''Negotiable''' – the Product Owner and the Team co-create the value and attributes of features (Stories)
'''Valuable''' – all Stories are connected directly to business value.
'''Estimable''' – the Team estimates the size of the Stories relative to each other.
'''Small''' – an important concept is raised here. Stories that are coming up in priority in the first or second Release should be small enough to be finished in one Sprint. Stories that are being implemented later can be large (Epics – more on this below).
'''Testable''' – knowing how we will know the Story is done, also called knowing the Definition of Done.

This review of the qualities of a good User Story gives some idea of the work to be done during Sprint Zero, while the User Stories are created, combined in one list, and then prioritized to make up the Product Backlog.

===Epic User Stories===

During Sprint Zero, the Product Owner will create a list of Epics. Epics are very large Stories. An example:
* As OSE, I want complete training materials in English for the 50 tools in GVCS on DVD, so that anyone with moderate experience in fabrication, and with access to the necessary tools and materials, can fabricate any of the 50 tools.

The list of Epics doesn't have to be exhaustive, but it should be thoroughly discussed and described, using the criteria for Stories developed in the video above.

===Definition of Done===

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=9FnZsaRujpw&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
NOTE -- this video is LOUD!

Review of the main concepts of the video:

This video is from Agile; Scrum is one form of Agile. So in this video you don't see mention of a Scrum Master. Instead they talk about a Team Lead. However, the content on Definition of Done is relevant for OSE.

In this video he is discussing creating the Definition of Done at the Team level. The Product Owner needs to first supply the Team with an initial Definition of Done feature by feature. The Product Owner's Definition of Done revolves around the What (and explains the Why). The Team's Definition of Done defines the How.

One value of this video is that it stresses how all members of a multi-functional Team get involved in creating the Definition of Done. It is crucial that this Definition is agreed to by everyone on the Team. When the Team commits to the work included in a Release, and in each Sprint, they are doing so based on the agreed on Definition of Done for each Story.

There is quite a bit of excess jargon in this video, but have patience, and relate it to GVCS. For example, we not only need to have the machine design "done," but also CAD drawings, an instructional video, and many other instructional components. Unifying the release and "done-ness" of all of these is what seems like the best, and most radical!, contribution Scrum can make to GVCS. These underlying points of “What is Done?” are crucial for us to understand the work that is needed in Sprint Zero.

==OSE [[GVCS]] Scrum==

Steps to take to convert OSE to Scrum:

1) Identify a Product Owner and Scrum Master
2) The Scrum Master helps the Product Owner identify the Stories and business values.
3) Decide whether to use collaborative online Scrum software (especially for the Product Backlog)
3) Decide who will participate in Sprint Zero, how long it will be, and the format.

First, we list the projects, in order of priority. See GVCS graphic on the right. Changes are: remove pyrolysis oil and [[Babington burner]] with biomass [[Pelletizer]] for fueling modern [[Steam Engine]]s. The burner is already present in the form of the [[:File:Gasifiericon.jpg|Gasifier Icon]]
[[Image:Slide1Linz7.jpg|thumb|40 [[GVCS]] technologies.]]
#CEB press - [[Full Product Release]] achieved.
#LifeTrac - on Prototype II
#Soil Pulverizer -

==See Also==

* [http://www.scrumhw.org/ Scrum for Hardware Product Development] ''Bringing Scrum to the Hardware Product Development Community''
* [http://maccherone.com/larry/2010/02/23/top-10-questions-when-using-agile-on-hardware-projects/ Top 10 questions when using Agile on hardware projects]

[[Category:Project Management]]

Scrum

2012-03-05T23:06:31Z

Mia Van Meter: /* Sprint ZERO */

Definition: '''[[wikipedia:Scrum (development)|Scrum]]''' is an iterative and incremental methodology for software projects and product- or application-development. It is also one of the variants of [[wikipedia:agile software development|agile software development]] methodologies.

==Why would a development team use Scrum?==

As demonstrated by high-powered software teams around the world, the Scrum process can increase a development team's efficiency dramatically. In recent years, some Scrum coaches (Scrum Masters) can consistently get development teams to be six times more efficient, and it is becoming almost unremarkable for a Scrum Master to kick a team into a productive state 15 times more productive than in their pre-Scrum days.

Scrum is essentially a double handful of rules for how a team should work together, and how they should be managed. Underneath those rules is a profound understanding of human nature. What motivates us? That is the essential question which Scrum answers. Scrum rules are designed to instill ownership, motivation, and creative problem-solving in team members. The dramatic results of a well-functioning Scrum team come from the synchronistic multiplying effect of a group of developers working “in the flow.” [http://en.wikipedia.org/wiki/Jeff_Sutherland/ Jeff Sutherland], one of the creators of Scrum, refers to these as “activated” teams.

Following [http://en.wikipedia.org/wiki/Lean_software_development/ Lean] development principles, the rules of Scrum are stripped down to the essentials. One of the implications of this is that teams must adopt all the Scrum rules in order to get Scrum results. Jeff Sutherland's favorite lecture topic seems to be “Scrumbutt.” This occurs when teams say, “Yes, we're doing Scrum, but...” and explain an aspect of Scrum they decided not to implement. According to Sutherland, you cannot get dramatic results unless you are pretty much a Scrum purist. That said, Scrum can “wrap around” other software development process technologies like, for example, XP or Lean. It's not essential to understand those technologies fully, for our purposes, but they are mentioned in the discussion on this page.

The most relevant question for a project like OSE is – is Scrum applicable outside the software development world? This is the answer that Joe Justice and the WikiSpeed team answer with a resounding “Yes!” In the 10-minute TEDX talk below, he explains briefly how the WikiSpeed Team, a collection of 44 volunteers in 4 countries, in three months used Scrum and associated processes to design and build a road-certifiable 4-person commuter car that can get over 100 miles per gallon in standard EPA road tests. The relevance of this to OSE is obvious – a distributed team of volunteers co-developing revolutionary hardware, sound familiar? It's well worth your while to spend a few hours absorbing the information on Scrum that this page points to, and to help explore its relevance for OSE in general, and the GVCS in particular.

In this video, Joe Justice, of WikiSpeed, explains the process his all-volunteer design team used to exceed expectations in their fuel-efficient car design.

<html><iframe width="300" height="182" src="http://www.youtube.com/watch?v=x8jdx-lf2Dw" frameborder="0" allowfullscreen></iframe></html>

.
.

.
.

==What is Scrum?==

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/watch?v=Q5k7a9YEoUI" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
The video above is a great first introduction to Scrum! It's fast paced, and the graphics easily convey the important information.

Of course, like any single Scrum coach, this one has his own take on Scrum, and in some instances it's likely that OSE Scrum will be different.

To review his core concepts:

Roles: Product Owner, Scrum Master, Team Members (developers, testers, customers)

Release Planning:
*Product Backlog– Estimate for each feature wanted in product.
*Release Backlog
*plan 4-12 Sprints – a substantive back log to a ship-ready state
*Sprint Backlog

Burndown Chart – day by day measure of the amount of work left in a Release, or Sprint

Bugs – have a separate Defect Backlog. Resolve bugs within the Sprint.

Daily Scrum – short, standing, identify bugs.

So that video is a great introduction to Scrum, but how would we actually get started?

The Scrum process starts with the Product Owner. They are responsible for creating the Product Backlog, creating the Development Team, and for providing the Team with the tools necessary for them to work. The Scrum Master helps the Product Owner with these tasks.

===Sprint ZERO===

To get ready for the first development Sprint, the Product Owner and the Scrum Master need to meet together, and with the Team, and do some initial preparation. The amount of time spent on Sprint Zero should be limited, and agreed upon in advance. Unfinished preparation can be added to the Product Backlog when Sprint Zero is finished. Additionally, the task of adding to the Product Backlog, and refining features that are down the road a bit, will be ongoing tasks for the Product Owner.

The most important outcome of Sprint Zero is to create understanding about the value of the work. Given that OSE might choose to have a team (Scrum) of Product Owners, it could make implementation more clear if the business values we are creating are explicitly ranked. Usually the process of identifying and clarifying the business value is held more distantly from the Team. In the case of OSE, it seems likely that a group of people will be determining the relative priorities of our business values, and the relative rankings of the features that we're planning on creating.

Here are some further questions to be taken up during Sprint Zero:
* Do we have the right people with the right skills? Is there a need for consultants, etc.?

* Given the Epic User Stories, the values, and the efinitions of done, what sort of work place, tools and technology set up are indicated?

* What is the general approach we are taking? What will be the length of our Sprints? What is the Road Map -- the key release points? How many teams will there be? If there are multiple teams, how will the Scrum Masters and the Product Owners from the multiple teams work together?

At the end of Sprint Zero, the Product Backlog must contain enough prioritized Stories to fill at least the first Release. Ideally, there would be enough Stories for two or three releases, so that the broad outlines of the technology and personnel needed can be understood.

Here's a possible outline for Sprint Zero:
Describe final product
Create a team(s) workspace(s)
Determine the length of sprints
Identify business value (the criteria to prioritize Stories)
Create epics. Prioritize epics (consider relative business value)
For the highest priority epic, turn the epic into stories
Prioritize the stories (consider relative business value)
For each story, create a definition of done

The following sections explain the Scrum terms needed to understand Sprint Zero work.

===User Stories===

We've been talking about ranking the features that make up the Product Backlog. In Scrum, these features are called Stories. There is an art to defining a Scrum Story, as you might imagine. Stories often take this form:

As _[User]_____, I want _[feature]_______, so that __[value]______.

An example:

* As a fabricator making a CNC Torch Table, I want complete and accurate CAD drawings, so that my efforts will result in a well-functioning machine.

Because the User is included in defining the feature, these are known as User Stories. The following video explains a good way to evaluate and improve User Stories, which are the list of features that make up the Product Backlog.

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=L_NyCczp0Fk&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.

To review the key ideas of the video:

'''Independent''' – dependencies among or between Stories need to be identified, eliminated, or tracked. An example of dependency: the training video for making a machine cannot be made until the machine is designed.
'''Negotiable''' – the Product Owner and the Team co-create the value and attributes of features (Stories)
'''Valuable''' – all Stories are connected directly to business value.
'''Estimable''' – the Team estimates the size of the Stories relative to each other.
'''Small''' – an important concept is raised here. Stories that are coming up in priority in the first or second Release should be small enough to be finished in one Sprint. Stories that are being implemented later can be large (Epics – more on this below).
'''Testable''' – knowing how we will know the Story is done, also called knowing the Definition of Done.

This review of the qualities of a good User Story gives some idea of the work to be done during Sprint Zero, while the User Stories are created, combined in one list, and then prioritized to make up the Product Backlog.

===Epic User Stories===

During Sprint Zero, the Product Owner will create a list of Epics. Epics are very large Stories. An example:
* As OSE, I want complete training materials in English for the 50 tools in GVCS on DVD, so that anyone with moderate experience in fabrication, and with access to the necessary tools and materials, can fabricate any of the 50 tools.

The list of Epics doesn't have to be exhaustive, but it should be thoroughly discussed and described, using the criteria for Stories developed in the video above.

===Definition of Done===

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=9FnZsaRujpw&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
NOTE -- this video is LOUD!

Review of the main concepts of the video:

This video is from Agile; Scrum is one form of Agile. So in this video you don't see mention of a Scrum Master. Instead they talk about a Team Lead. However, the content on Definition of Done is relevant for OSE.

In this video he is discussing creating the Definition of Done at the Team level. The Product Owner needs to first supply the Team with an initial Definition of Done feature by feature. The Product Owner's Definition of Done revolves around the What (and explains the Why). The Team's Definition of Done defines the How.

One value of this video is that it stresses how all members of a multi-functional Team get involved in creating the Definition of Done. It is crucial that this Definition is agreed to by everyone on the Team. When the Team commits to the work included in a Release, and in each Sprint, they are doing so based on the agreed on Definition of Done for each Story.

There is quite a bit of excess jargon in this video, but have patience, and relate it to GVCS. For example, we not only need to have the machine design "done," but also CAD drawings, an instructional video, and many other instructional components. Unifying the release and "done-ness" of all of these is what seems like the best, and most radical!, contribution Scrum can make to GVCS. These underlying points of “What is Done?” are crucial for us to understand the work that is needed in Sprint Zero.

==OSE [[GVCS]] Scrum==

Steps to take to convert OSE to Scrum:

1) Identify a Product Owner and Scrum Master
2) The Scrum Master helps the Product Owner identify the Stories and business values.
3) Decide whether to use collaborative online Scrum software (especially for the Product Backlog)
3) Decide who will participate in Sprint Zero, how long it will be, and the format.

First, we list the projects, in order of priority. See GVCS graphic on the right. Changes are: remove pyrolysis oil and [[Babington burner]] with biomass [[Pelletizer]] for fueling modern [[Steam Engine]]s. The burner is already present in the form of the [[:File:Gasifiericon.jpg|Gasifier Icon]]
[[Image:Slide1Linz7.jpg|thumb|40 [[GVCS]] technologies.]]
#CEB press - [[Full Product Release]] achieved.
#LifeTrac - on Prototype II
#Soil Pulverizer -

==See Also==

* [http://www.scrumhw.org/ Scrum for Hardware Product Development] ''Bringing Scrum to the Hardware Product Development Community''
* [http://maccherone.com/larry/2010/02/23/top-10-questions-when-using-agile-on-hardware-projects/ Top 10 questions when using Agile on hardware projects]

[[Category:Project Management]]

Scrum

2012-03-05T22:57:14Z

Mia Van Meter: /* Definition of Done */

Definition: '''[[wikipedia:Scrum (development)|Scrum]]''' is an iterative and incremental methodology for software projects and product- or application-development. It is also one of the variants of [[wikipedia:agile software development|agile software development]] methodologies.

==Why would a development team use Scrum?==

As demonstrated by high-powered software teams around the world, the Scrum process can increase a development team's efficiency dramatically. In recent years, some Scrum coaches (Scrum Masters) can consistently get development teams to be six times more efficient, and it is becoming almost unremarkable for a Scrum Master to kick a team into a productive state 15 times more productive than in their pre-Scrum days.

Scrum is essentially a double handful of rules for how a team should work together, and how they should be managed. Underneath those rules is a profound understanding of human nature. What motivates us? That is the essential question which Scrum answers. Scrum rules are designed to instill ownership, motivation, and creative problem-solving in team members. The dramatic results of a well-functioning Scrum team come from the synchronistic multiplying effect of a group of developers working “in the flow.” [http://en.wikipedia.org/wiki/Jeff_Sutherland/ Jeff Sutherland], one of the creators of Scrum, refers to these as “activated” teams.

Following [http://en.wikipedia.org/wiki/Lean_software_development/ Lean] development principles, the rules of Scrum are stripped down to the essentials. One of the implications of this is that teams must adopt all the Scrum rules in order to get Scrum results. Jeff Sutherland's favorite lecture topic seems to be “Scrumbutt.” This occurs when teams say, “Yes, we're doing Scrum, but...” and explain an aspect of Scrum they decided not to implement. According to Sutherland, you cannot get dramatic results unless you are pretty much a Scrum purist. That said, Scrum can “wrap around” other software development process technologies like, for example, XP or Lean. It's not essential to understand those technologies fully, for our purposes, but they are mentioned in the discussion on this page.

The most relevant question for a project like OSE is – is Scrum applicable outside the software development world? This is the answer that Joe Justice and the WikiSpeed team answer with a resounding “Yes!” In the 10-minute TEDX talk below, he explains briefly how the WikiSpeed Team, a collection of 44 volunteers in 4 countries, in three months used Scrum and associated processes to design and build a road-certifiable 4-person commuter car that can get over 100 miles per gallon in standard EPA road tests. The relevance of this to OSE is obvious – a distributed team of volunteers co-developing revolutionary hardware, sound familiar? It's well worth your while to spend a few hours absorbing the information on Scrum that this page points to, and to help explore its relevance for OSE in general, and the GVCS in particular.

In this video, Joe Justice, of WikiSpeed, explains the process his all-volunteer design team used to exceed expectations in their fuel-efficient car design.

<html><iframe width="300" height="182" src="http://www.youtube.com/watch?v=x8jdx-lf2Dw" frameborder="0" allowfullscreen></iframe></html>

.
.

.
.

==What is Scrum?==

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/watch?v=Q5k7a9YEoUI" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
The video above is a great first introduction to Scrum! It's fast paced, and the graphics easily convey the important information.

Of course, like any single Scrum coach, this one has his own take on Scrum, and in some instances it's likely that OSE Scrum will be different.

To review his core concepts:

Roles: Product Owner, Scrum Master, Team Members (developers, testers, customers)

Release Planning:
*Product Backlog– Estimate for each feature wanted in product.
*Release Backlog
*plan 4-12 Sprints – a substantive back log to a ship-ready state
*Sprint Backlog

Burndown Chart – day by day measure of the amount of work left in a Release, or Sprint

Bugs – have a separate Defect Backlog. Resolve bugs within the Sprint.

Daily Scrum – short, standing, identify bugs.

So that video is a great introduction to Scrum, but how would we actually get started?

The Scrum process starts with the Product Owner. They are responsible for creating the Product Backlog, creating the Development Team, and for providing the Team with the tools necessary for them to work. The Scrum Master helps the Product Owner with these tasks.

===Sprint ZERO===

To get ready for the first development Sprint, the Product Owner and the Scrum Master need to meet together, and with the Team, and do some initial preparation. The amount of time spent on Sprint Zero should be limited, and agreed upon in advance. Unfinished preparation can be added to the Product Backlog when Sprint Zero is finished. Additionally, the task of adding to the Product Backlog, and refining features that are down the road a bit, will be ongoing tasks for the Product Owner.

The most important outcome of Sprint Zero is to create understanding about the value of the work. Given that OSE might choose to have a team (Scrum) of Product Owners, it could make implementation more clear if the business values we are creating are explicitly ranked. Usually the process of identifying and clarifying the business value is held more distantly from the Team. In the case of OSE, it seems likely that a group of people will be determining the relative priorities of our business values, and the relative rankings of the features that we're planning on creating.

Here are some further questions to be taken up during Sprint Zero:
* Do we have the right people with the right skills? Is there a need for consultants, etc.?

* Given the Epic User Stories, the values, and the efinitions of done, what sort of work place, tools and technology set up are indicated?

* What is the general approach we are taking? What will be the length of our Sprints? What is the Road Map -- the key release points? How many teams will there be? If there are multiple teams, how will the Scrum Masters and the Product Owners from the multiple teams work together?

At the end of Sprint Zero, the Product Backlog must contain enough prioritized Stories to fill at least the first Release. Ideally, there would be enough Stories for two or three releases, so that the broad outlines of the technology and personnel needed can be understood.

Here's a possible outline for Sprint Zero:
Describe final product
Create a team(s) workspace(s)
Determine the length of sprints
Identify business value (the criteria to measure the value of work as it's done)
Create epics. Prioritize epics (consider relative business value)
For the highest priority epic, turn the epic into stories
Prioritize the stories (consider relative business value)
For each story, create a definition of done

The following sections explain the Scrum terms needed to understand Sprint Zero work.

===User Stories===

We've been talking about ranking the features that make up the Product Backlog. In Scrum, these features are called Stories. There is an art to defining a Scrum Story, as you might imagine. Stories often take this form:

As _[User]_____, I want _[feature]_______, so that __[value]______.

An example:

* As a fabricator making a CNC Torch Table, I want complete and accurate CAD drawings, so that my efforts will result in a well-functioning machine.

Because the User is included in defining the feature, these are known as User Stories. The following video explains a good way to evaluate and improve User Stories, which are the list of features that make up the Product Backlog.

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=L_NyCczp0Fk&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.

To review the key ideas of the video:

'''Independent''' – dependencies among or between Stories need to be identified, eliminated, or tracked. An example of dependency: the training video for making a machine cannot be made until the machine is designed.
'''Negotiable''' – the Product Owner and the Team co-create the value and attributes of features (Stories)
'''Valuable''' – all Stories are connected directly to business value.
'''Estimable''' – the Team estimates the size of the Stories relative to each other.
'''Small''' – an important concept is raised here. Stories that are coming up in priority in the first or second Release should be small enough to be finished in one Sprint. Stories that are being implemented later can be large (Epics – more on this below).
'''Testable''' – knowing how we will know the Story is done, also called knowing the Definition of Done.

This review of the qualities of a good User Story gives some idea of the work to be done during Sprint Zero, while the User Stories are created, combined in one list, and then prioritized to make up the Product Backlog.

===Epic User Stories===

During Sprint Zero, the Product Owner will create a list of Epics. Epics are very large Stories. An example:
* As OSE, I want complete training materials in English for the 50 tools in GVCS on DVD, so that anyone with moderate experience in fabrication, and with access to the necessary tools and materials, can fabricate any of the 50 tools.

The list of Epics doesn't have to be exhaustive, but it should be thoroughly discussed and described, using the criteria for Stories developed in the video above.

===Definition of Done===

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=9FnZsaRujpw&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
NOTE -- this video is LOUD!

Review of the main concepts of the video:

This video is from Agile; Scrum is one form of Agile. So in this video you don't see mention of a Scrum Master. Instead they talk about a Team Lead. However, the content on Definition of Done is relevant for OSE.

In this video he is discussing creating the Definition of Done at the Team level. The Product Owner needs to first supply the Team with an initial Definition of Done feature by feature. The Product Owner's Definition of Done revolves around the What (and explains the Why). The Team's Definition of Done defines the How.

One value of this video is that it stresses how all members of a multi-functional Team get involved in creating the Definition of Done. It is crucial that this Definition is agreed to by everyone on the Team. When the Team commits to the work included in a Release, and in each Sprint, they are doing so based on the agreed on Definition of Done for each Story.

There is quite a bit of excess jargon in this video, but have patience, and relate it to GVCS. For example, we not only need to have the machine design "done," but also CAD drawings, an instructional video, and many other instructional components. Unifying the release and "done-ness" of all of these is what seems like the best, and most radical!, contribution Scrum can make to GVCS. These underlying points of “What is Done?” are crucial for us to understand the work that is needed in Sprint Zero.

==OSE [[GVCS]] Scrum==

Steps to take to convert OSE to Scrum:

1) Identify a Product Owner and Scrum Master
2) The Scrum Master helps the Product Owner identify the Stories and business values.
3) Decide whether to use collaborative online Scrum software (especially for the Product Backlog)
3) Decide who will participate in Sprint Zero, how long it will be, and the format.

First, we list the projects, in order of priority. See GVCS graphic on the right. Changes are: remove pyrolysis oil and [[Babington burner]] with biomass [[Pelletizer]] for fueling modern [[Steam Engine]]s. The burner is already present in the form of the [[:File:Gasifiericon.jpg|Gasifier Icon]]
[[Image:Slide1Linz7.jpg|thumb|40 [[GVCS]] technologies.]]
#CEB press - [[Full Product Release]] achieved.
#LifeTrac - on Prototype II
#Soil Pulverizer -

==See Also==

* [http://www.scrumhw.org/ Scrum for Hardware Product Development] ''Bringing Scrum to the Hardware Product Development Community''
* [http://maccherone.com/larry/2010/02/23/top-10-questions-when-using-agile-on-hardware-projects/ Top 10 questions when using Agile on hardware projects]

[[Category:Project Management]]

Scrum

2012-03-05T22:56:24Z

Mia Van Meter: /* Sprint ZERO */ pull the general material into one section

Definition: '''[[wikipedia:Scrum (development)|Scrum]]''' is an iterative and incremental methodology for software projects and product- or application-development. It is also one of the variants of [[wikipedia:agile software development|agile software development]] methodologies.

==Why would a development team use Scrum?==

As demonstrated by high-powered software teams around the world, the Scrum process can increase a development team's efficiency dramatically. In recent years, some Scrum coaches (Scrum Masters) can consistently get development teams to be six times more efficient, and it is becoming almost unremarkable for a Scrum Master to kick a team into a productive state 15 times more productive than in their pre-Scrum days.

Scrum is essentially a double handful of rules for how a team should work together, and how they should be managed. Underneath those rules is a profound understanding of human nature. What motivates us? That is the essential question which Scrum answers. Scrum rules are designed to instill ownership, motivation, and creative problem-solving in team members. The dramatic results of a well-functioning Scrum team come from the synchronistic multiplying effect of a group of developers working “in the flow.” [http://en.wikipedia.org/wiki/Jeff_Sutherland/ Jeff Sutherland], one of the creators of Scrum, refers to these as “activated” teams.

Following [http://en.wikipedia.org/wiki/Lean_software_development/ Lean] development principles, the rules of Scrum are stripped down to the essentials. One of the implications of this is that teams must adopt all the Scrum rules in order to get Scrum results. Jeff Sutherland's favorite lecture topic seems to be “Scrumbutt.” This occurs when teams say, “Yes, we're doing Scrum, but...” and explain an aspect of Scrum they decided not to implement. According to Sutherland, you cannot get dramatic results unless you are pretty much a Scrum purist. That said, Scrum can “wrap around” other software development process technologies like, for example, XP or Lean. It's not essential to understand those technologies fully, for our purposes, but they are mentioned in the discussion on this page.

The most relevant question for a project like OSE is – is Scrum applicable outside the software development world? This is the answer that Joe Justice and the WikiSpeed team answer with a resounding “Yes!” In the 10-minute TEDX talk below, he explains briefly how the WikiSpeed Team, a collection of 44 volunteers in 4 countries, in three months used Scrum and associated processes to design and build a road-certifiable 4-person commuter car that can get over 100 miles per gallon in standard EPA road tests. The relevance of this to OSE is obvious – a distributed team of volunteers co-developing revolutionary hardware, sound familiar? It's well worth your while to spend a few hours absorbing the information on Scrum that this page points to, and to help explore its relevance for OSE in general, and the GVCS in particular.

In this video, Joe Justice, of WikiSpeed, explains the process his all-volunteer design team used to exceed expectations in their fuel-efficient car design.

<html><iframe width="300" height="182" src="http://www.youtube.com/watch?v=x8jdx-lf2Dw" frameborder="0" allowfullscreen></iframe></html>

.
.

.
.

==What is Scrum?==

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/watch?v=Q5k7a9YEoUI" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
The video above is a great first introduction to Scrum! It's fast paced, and the graphics easily convey the important information.

Of course, like any single Scrum coach, this one has his own take on Scrum, and in some instances it's likely that OSE Scrum will be different.

To review his core concepts:

Roles: Product Owner, Scrum Master, Team Members (developers, testers, customers)

Release Planning:
*Product Backlog– Estimate for each feature wanted in product.
*Release Backlog
*plan 4-12 Sprints – a substantive back log to a ship-ready state
*Sprint Backlog

Burndown Chart – day by day measure of the amount of work left in a Release, or Sprint

Bugs – have a separate Defect Backlog. Resolve bugs within the Sprint.

Daily Scrum – short, standing, identify bugs.

So that video is a great introduction to Scrum, but how would we actually get started?

The Scrum process starts with the Product Owner. They are responsible for creating the Product Backlog, creating the Development Team, and for providing the Team with the tools necessary for them to work. The Scrum Master helps the Product Owner with these tasks.

===Sprint ZERO===

To get ready for the first development Sprint, the Product Owner and the Scrum Master need to meet together, and with the Team, and do some initial preparation. The amount of time spent on Sprint Zero should be limited, and agreed upon in advance. Unfinished preparation can be added to the Product Backlog when Sprint Zero is finished. Additionally, the task of adding to the Product Backlog, and refining features that are down the road a bit, will be ongoing tasks for the Product Owner.

The most important outcome of Sprint Zero is to create understanding about the value of the work. Given that OSE might choose to have a team (Scrum) of Product Owners, it could make implementation more clear if the business values we are creating are explicitly ranked. Usually the process of identifying and clarifying the business value is held more distantly from the Team. In the case of OSE, it seems likely that a group of people will be determining the relative priorities of our business values, and the relative rankings of the features that we're planning on creating.

Here are some further questions to be taken up during Sprint Zero:
* Do we have the right people with the right skills? Is there a need for consultants, etc.?

* Given the Epic User Stories, the values, and the efinitions of done, what sort of work place, tools and technology set up are indicated?

* What is the general approach we are taking? What will be the length of our Sprints? What is the Road Map -- the key release points? How many teams will there be? If there are multiple teams, how will the Scrum Masters and the Product Owners from the multiple teams work together?

At the end of Sprint Zero, the Product Backlog must contain enough prioritized Stories to fill at least the first Release. Ideally, there would be enough Stories for two or three releases, so that the broad outlines of the technology and personnel needed can be understood.

Here's a possible outline for Sprint Zero:
Describe final product
Create a team(s) workspace(s)
Determine the length of sprints
Identify business value (the criteria to measure the value of work as it's done)
Create epics. Prioritize epics (consider relative business value)
For the highest priority epic, turn the epic into stories
Prioritize the stories (consider relative business value)
For each story, create a definition of done

The following sections explain the Scrum terms needed to understand Sprint Zero work.

===User Stories===

We've been talking about ranking the features that make up the Product Backlog. In Scrum, these features are called Stories. There is an art to defining a Scrum Story, as you might imagine. Stories often take this form:

As _[User]_____, I want _[feature]_______, so that __[value]______.

An example:

* As a fabricator making a CNC Torch Table, I want complete and accurate CAD drawings, so that my efforts will result in a well-functioning machine.

Because the User is included in defining the feature, these are known as User Stories. The following video explains a good way to evaluate and improve User Stories, which are the list of features that make up the Product Backlog.

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=L_NyCczp0Fk&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.

To review the key ideas of the video:

'''Independent''' – dependencies among or between Stories need to be identified, eliminated, or tracked. An example of dependency: the training video for making a machine cannot be made until the machine is designed.
'''Negotiable''' – the Product Owner and the Team co-create the value and attributes of features (Stories)
'''Valuable''' – all Stories are connected directly to business value.
'''Estimable''' – the Team estimates the size of the Stories relative to each other.
'''Small''' – an important concept is raised here. Stories that are coming up in priority in the first or second Release should be small enough to be finished in one Sprint. Stories that are being implemented later can be large (Epics – more on this below).
'''Testable''' – knowing how we will know the Story is done, also called knowing the Definition of Done.

This review of the qualities of a good User Story gives some idea of the work to be done during Sprint Zero, while the User Stories are created, combined in one list, and then prioritized to make up the Product Backlog.

===Epic User Stories===

During Sprint Zero, the Product Owner will create a list of Epics. Epics are very large Stories. An example:
* As OSE, I want complete training materials in English for the 50 tools in GVCS on DVD, so that anyone with moderate experience in fabrication, and with access to the necessary tools and materials, can fabricate any of the 50 tools.

The list of Epics doesn't have to be exhaustive, but it should be thoroughly discussed and described, using the criteria for Stories developed in the video above.

===Definition of Done===

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=9FnZsaRujpw&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
NOTE -- this video is LOUD!

Review of the main concepts of the video:

This video is from Agile; Scrum is one form of Agile. So in this video you don't see mention of a Scrum Master. Instead they talk about a Team Lead. However, the content on Definition of Done is relevant for OSE.

In this video he is discussing creating the Definition of Done at the Team level. The Product Owner needs to first supply the Team with an initial Definition of Done feature by feature. The Product Owner's Definition of Done revolves around the What (and explains the Why). The Team's Definition of Done defines the How.

In the video, he refers to "blockers," which are usually referred to in Scrum as Impediments. More on that later...

One value of this video is that it stresses how all members of a multi-functional Team get involved in creating the Definition of Done. It is crucial that this Definition is agreed to by everyone on the Team. When the Team commits to the work included in a Release, and in each Sprint, they are doing so based on the agreed on Definition of Done for each Story.

There is quite a bit of excess jargon in this video, but have patience, and relate it to GVCS. For example, we not only need to have the machine design "done," but also CAD drawings, an instructional video, and many other instructional components. Unifying the release and "done-ness" of all of these is what seems like the best, and most radical!, contribution Scrum can make to GVCS. These underlying points of “What is Done?” are crucial for us to understand the work that is needed in Sprint Zero.

==OSE [[GVCS]] Scrum==

Steps to take to convert OSE to Scrum:

1) Identify a Product Owner and Scrum Master
2) The Scrum Master helps the Product Owner identify the Stories and business values.
3) Decide whether to use collaborative online Scrum software (especially for the Product Backlog)
3) Decide who will participate in Sprint Zero, how long it will be, and the format.

First, we list the projects, in order of priority. See GVCS graphic on the right. Changes are: remove pyrolysis oil and [[Babington burner]] with biomass [[Pelletizer]] for fueling modern [[Steam Engine]]s. The burner is already present in the form of the [[:File:Gasifiericon.jpg|Gasifier Icon]]
[[Image:Slide1Linz7.jpg|thumb|40 [[GVCS]] technologies.]]
#CEB press - [[Full Product Release]] achieved.
#LifeTrac - on Prototype II
#Soil Pulverizer -

==See Also==

* [http://www.scrumhw.org/ Scrum for Hardware Product Development] ''Bringing Scrum to the Hardware Product Development Community''
* [http://maccherone.com/larry/2010/02/23/top-10-questions-when-using-agile-on-hardware-projects/ Top 10 questions when using Agile on hardware projects]

[[Category:Project Management]]

Scrum

2012-03-05T22:54:32Z

Mia Van Meter:

Definition: '''[[wikipedia:Scrum (development)|Scrum]]''' is an iterative and incremental methodology for software projects and product- or application-development. It is also one of the variants of [[wikipedia:agile software development|agile software development]] methodologies.

==Why would a development team use Scrum?==

As demonstrated by high-powered software teams around the world, the Scrum process can increase a development team's efficiency dramatically. In recent years, some Scrum coaches (Scrum Masters) can consistently get development teams to be six times more efficient, and it is becoming almost unremarkable for a Scrum Master to kick a team into a productive state 15 times more productive than in their pre-Scrum days.

Scrum is essentially a double handful of rules for how a team should work together, and how they should be managed. Underneath those rules is a profound understanding of human nature. What motivates us? That is the essential question which Scrum answers. Scrum rules are designed to instill ownership, motivation, and creative problem-solving in team members. The dramatic results of a well-functioning Scrum team come from the synchronistic multiplying effect of a group of developers working “in the flow.” [http://en.wikipedia.org/wiki/Jeff_Sutherland/ Jeff Sutherland], one of the creators of Scrum, refers to these as “activated” teams.

Following [http://en.wikipedia.org/wiki/Lean_software_development/ Lean] development principles, the rules of Scrum are stripped down to the essentials. One of the implications of this is that teams must adopt all the Scrum rules in order to get Scrum results. Jeff Sutherland's favorite lecture topic seems to be “Scrumbutt.” This occurs when teams say, “Yes, we're doing Scrum, but...” and explain an aspect of Scrum they decided not to implement. According to Sutherland, you cannot get dramatic results unless you are pretty much a Scrum purist. That said, Scrum can “wrap around” other software development process technologies like, for example, XP or Lean. It's not essential to understand those technologies fully, for our purposes, but they are mentioned in the discussion on this page.

The most relevant question for a project like OSE is – is Scrum applicable outside the software development world? This is the answer that Joe Justice and the WikiSpeed team answer with a resounding “Yes!” In the 10-minute TEDX talk below, he explains briefly how the WikiSpeed Team, a collection of 44 volunteers in 4 countries, in three months used Scrum and associated processes to design and build a road-certifiable 4-person commuter car that can get over 100 miles per gallon in standard EPA road tests. The relevance of this to OSE is obvious – a distributed team of volunteers co-developing revolutionary hardware, sound familiar? It's well worth your while to spend a few hours absorbing the information on Scrum that this page points to, and to help explore its relevance for OSE in general, and the GVCS in particular.

In this video, Joe Justice, of WikiSpeed, explains the process his all-volunteer design team used to exceed expectations in their fuel-efficient car design.

<html><iframe width="300" height="182" src="http://www.youtube.com/watch?v=x8jdx-lf2Dw" frameborder="0" allowfullscreen></iframe></html>

.
.

.
.

==What is Scrum?==

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/watch?v=Q5k7a9YEoUI" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
The video above is a great first introduction to Scrum! It's fast paced, and the graphics easily convey the important information.

Of course, like any single Scrum coach, this one has his own take on Scrum, and in some instances it's likely that OSE Scrum will be different.

To review his core concepts:

Roles: Product Owner, Scrum Master, Team Members (developers, testers, customers)

Release Planning:
*Product Backlog– Estimate for each feature wanted in product.
*Release Backlog
*plan 4-12 Sprints – a substantive back log to a ship-ready state
*Sprint Backlog

Burndown Chart – day by day measure of the amount of work left in a Release, or Sprint

Bugs – have a separate Defect Backlog. Resolve bugs within the Sprint.

Daily Scrum – short, standing, identify bugs.

So that video is a great introduction to Scrum, but how would we actually get started?

The Scrum process starts with the Product Owner. They are responsible for creating the Product Backlog, creating the Development Team, and for providing the Team with the tools necessary for them to work. The Scrum Master helps the Product Owner with these tasks.

===Sprint ZERO===

To get ready for the first development Sprint, the Product Owner and the Scrum Master need to meet together, and with the Team, and do some initial preparation. The amount of time spent on Sprint Zero should be limited, and agreed upon in advance. Unfinished preparation can be added to the Product Backlog when Sprint Zero is finished. Additionally, the task of adding to the Product Backlog, and refining features that are down the road a bit, will be ongoing tasks for the Product Owner.

The most important outcome of Sprint Zero is to create understanding about the value of the work. Given that OSE might choose to have a team (Scrum) of Product Owners, it could make implementation more clear if the business values we are creating are explicitly ranked. Usually the process of identifying and clarifying the business value is held more distantly from the Team. In the case of OSE, it seems likely that a group of people will be determining the relative priorities of our business values, and the relative rankings of the features that we're planning on creating.

Here's a possible outline for Sprint Zero:
Describe final product
Create a team(s) workspace(s)
Determine the length of sprints
Identify business value (the criteria to measure the value of work as it's done)
Create epics. Prioritize epics (consider relative business value)
For the highest priority epic, turn the epic into stories
Prioritize the stories (consider relative business value)
For each story, create a definition of done

===User Stories===

We've been talking about ranking the features that make up the Product Backlog. In Scrum, these features are called Stories. There is an art to defining a Scrum Story, as you might imagine. Stories often take this form:

As _[User]_____, I want _[feature]_______, so that __[value]______.

An example:

* As a fabricator making a CNC Torch Table, I want complete and accurate CAD drawings, so that my efforts will result in a well-functioning machine.

Because the User is included in defining the feature, these are known as User Stories. The following video explains a good way to evaluate and improve User Stories, which are the list of features that make up the Product Backlog.

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=L_NyCczp0Fk&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.

To review the key ideas of the video:

'''Independent''' – dependencies among or between Stories need to be identified, eliminated, or tracked. An example of dependency: the training video for making a machine cannot be made until the machine is designed.
'''Negotiable''' – the Product Owner and the Team co-create the value and attributes of features (Stories)
'''Valuable''' – all Stories are connected directly to business value.
'''Estimable''' – the Team estimates the size of the Stories relative to each other.
'''Small''' – an important concept is raised here. Stories that are coming up in priority in the first or second Release should be small enough to be finished in one Sprint. Stories that are being implemented later can be large (Epics – more on this below).
'''Testable''' – knowing how we will know the Story is done, also called knowing the Definition of Done.

This review of the qualities of a good User Story gives some idea of the work to be done during Sprint Zero, while the User Stories are created, combined in one list, and then prioritized to make up the Product Backlog.

===Epic User Stories===

During Sprint Zero, the Product Owner will create a list of Epics. Epics are very large Stories. An example:
* As OSE, I want complete training materials in English for the 50 tools in GVCS on DVD, so that anyone with moderate experience in fabrication, and with access to the necessary tools and materials, can fabricate any of the 50 tools.

The list of Epics doesn't have to be exhaustive, but it should be thoroughly discussed and described, using the criteria for Stories developed in the video above.

===Definition of Done===

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=9FnZsaRujpw&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
NOTE -- this video is LOUD!

Review of the main concepts of the video:

This video is from Agile; Scrum is one form of Agile. So in this video you don't see mention of a Scrum Master. Instead they talk about a Team Lead. However, the content on Definition of Done is relevant for OSE.

In this video he is discussing creating the Definition of Done at the Team level. The Product Owner needs to first supply the Team with an initial Definition of Done feature by feature. The Product Owner's Definition of Done revolves around the What (and explains the Why). The Team's Definition of Done defines the How.

In the video, he refers to "blockers," which are usually referred to in Scrum as Impediments. More on that later...

One value of this video is that it stresses how all members of a multi-functional Team get involved in creating the Definition of Done. It is crucial that this Definition is agreed to by everyone on the Team. When the Team commits to the work included in a Release, and in each Sprint, they are doing so based on the agreed on Definition of Done for each Story.

There is quite a bit of excess jargon in this video, but have patience, and relate it to GVCS. For example, we not only need to have the machine design "done," but also CAD drawings, an instructional video, and many other instructional components. Unifying the release and "done-ness" of all of these is what seems like the best, and most radical!, contribution Scrum can make to GVCS. These underlying points of “What is Done?” are crucial for us to understand the work that is needed in Sprint Zero.

==OSE [[GVCS]] Scrum==

Steps to take to convert OSE to Scrum:

1) Identify a Product Owner and Scrum Master
2) The Scrum Master helps the Product Owner identify the Stories and business values.
3) Decide whether to use collaborative online Scrum software (especially for the Product Backlog)
3) Decide who will participate in Sprint Zero, how long it will be, and the format.

First, we list the projects, in order of priority. See GVCS graphic on the right. Changes are: remove pyrolysis oil and [[Babington burner]] with biomass [[Pelletizer]] for fueling modern [[Steam Engine]]s. The burner is already present in the form of the [[:File:Gasifiericon.jpg|Gasifier Icon]]
[[Image:Slide1Linz7.jpg|thumb|40 [[GVCS]] technologies.]]
#CEB press - [[Full Product Release]] achieved.
#LifeTrac - on Prototype II
#Soil Pulverizer -

==See Also==

* [http://www.scrumhw.org/ Scrum for Hardware Product Development] ''Bringing Scrum to the Hardware Product Development Community''
* [http://maccherone.com/larry/2010/02/23/top-10-questions-when-using-agile-on-hardware-projects/ Top 10 questions when using Agile on hardware projects]

[[Category:Project Management]]

Scrum

2012-03-05T22:53:59Z

Mia Van Meter: /* Sprint ZERO */

Definition: '''[[wikipedia:Scrum (development)|Scrum]]''' is an iterative and incremental methodology for software projects and product- or application-development. It is also one of the variants of [[wikipedia:agile software development|agile software development]] methodologies.

==Why would a development team use Scrum?==

As demonstrated by high-powered software teams around the world, the Scrum process can increase a development team's efficiency dramatically. In recent years, some Scrum coaches (Scrum Masters) can consistently get development teams to be six times more efficient, and it is becoming almost unremarkable for a Scrum Master to kick a team into a productive state 15 times more productive than in their pre-Scrum days.

Scrum is essentially a double handful of rules for how a team should work together, and how they should be managed. Underneath those rules is a profound understanding of human nature. What motivates us? That is the essential question which Scrum answers. Scrum rules are designed to instill ownership, motivation, and creative problem-solving in team members. The dramatic results of a well-functioning Scrum team come from the synchronistic multiplying effect of a group of developers working “in the flow.” [http://en.wikipedia.org/wiki/Jeff_Sutherland/ Jeff Sutherland], one of the creators of Scrum, refers to these as “activated” teams.

Following [http://en.wikipedia.org/wiki/Lean_software_development/ Lean] development principles, the rules of Scrum are stripped down to the essentials. One of the implications of this is that teams must adopt all the Scrum rules in order to get Scrum results. Jeff Sutherland's favorite lecture topic seems to be “Scrumbutt.” This occurs when teams say, “Yes, we're doing Scrum, but...” and explain an aspect of Scrum they decided not to implement. According to Sutherland, you cannot get dramatic results unless you are pretty much a Scrum purist. That said, Scrum can “wrap around” other software development process technologies like, for example, XP or Lean. It's not essential to understand those technologies fully, for our purposes, but they are mentioned in the discussion on this page.

The most relevant question for a project like OSE is – is Scrum applicable outside the software development world? This is the answer that Joe Justice and the WikiSpeed team answer with a resounding “Yes!” In the 10-minute TEDX talk below, he explains briefly how the WikiSpeed Team, a collection of 44 volunteers in 4 countries, in three months used Scrum and associated processes to design and build a road-certifiable 4-person commuter car that can get over 100 miles per gallon in standard EPA road tests. The relevance of this to OSE is obvious – a distributed team of volunteers co-developing revolutionary hardware, sound familiar? It's well worth your while to spend a few hours absorbing the information on Scrum that this page points to, and to help explore its relevance for OSE in general, and the GVCS in particular.

In this video, Joe Justice, of WikiSpeed, explains the process his all-volunteer design team used to exceed expectations in their fuel-efficient car design.

<html><iframe width="300" height="182" src="http://www.youtube.com/watch?v=x8jdx-lf2Dw" frameborder="0" allowfullscreen></iframe></html>

.
.

.
.

==What is Scrum?==

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/watch?v=Q5k7a9YEoUI" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
The video above is a great first introduction to Scrum! It's fast paced, and the graphics easily convey the important information.

Of course, like any single Scrum coach, this one has his own take on Scrum, and in some instances it's likely that OSE Scrum will be different.

To review his core concepts:

Roles: Product Owner, Scrum Master, Team Members (developers, testers, customers)

Release Planning:
*Product Backlog– Estimate for each feature wanted in product.
*Release Backlog
*plan 4-12 Sprints – a substantive back log to a ship-ready state
*Sprint Backlog

Burndown Chart – day by day measure of the amount of work left in a Release, or Sprint

Bugs – have a separate Defect Backlog. Resolve bugs within the Sprint.

Daily Scrum – short, standing, identify bugs.

So that video is a great introduction to Scrum, but how would we actually get started?

The Scrum process starts with the Product Owner. They are responsible for creating the Product Backlog, creating the Development Team, and for providing the Team with the tools necessary for them to work. The Scrum Master helps the Product Owner with these tasks.

===Sprint ZERO===

To get ready for the first development Sprint, the Product Owner and the Scrum Master need to meet together, and with the Team, and do some initial preparation. The amount of time spent on Sprint Zero should be limited, and agreed upon in advance. Unfinished preparation can be added to the Product Backlog when Sprint Zero is finished. Additionally, the task of adding to the Product Backlog, and refining features that are down the road a bit, will be ongoing tasks for the Product Owner.

The most important outcome of Sprint Zero is to create understanding about the value of the work. Given that OSE might choose to have a team (Scrum) of Product Owners, it could make implementation more clear if the business values we are creating are explicitly ranked. Usually the process of identifying and clarifying the business value is held more distantly from the Team. In the case of OSE, it seems likely that a group of people will be determining the relative priorities of our business values, and the relative rankings of the features that we're planning on creating.

Here's a possible outline for Sprint Zero:
Describe final product
Create a team(s) workspace(s)
Determine the length of sprints
Identify business value (the criteria to measure the value of work as it's done)
Create epics. Prioritize epics (consider relative business value)
For the highest priority epic, turn the epic into stories
Prioritize the stories (consider relative business value)
For each story, create a definition of done

===User Stories===

We've been talking about ranking the features that make up the Product Backlog. In Scrum, these features are called Stories. There is an art to defining a Scrum Story, as you might imagine. Stories often take this form:

As _[User]_____, I want _[feature]_______, so that __[value]______.

An example:

* As a fabricator making a CNC Torch Table, I want complete and accurate CAD drawings, so that my efforts will result in a well-functioning machine.

Because the User is included in defining the feature, these are known as User Stories. The following video explains a good way to evaluate and improve User Stories, which are the list of features that make up the Product Backlog.

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=L_NyCczp0Fk&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.

To review the key ideas of the video:

'''Independent''' – dependencies among or between Stories need to be identified, eliminated, or tracked. An example of dependency: the training video for making a machine cannot be made until the machine is designed.
'''Negotiable''' – the Product Owner and the Team co-create the value and attributes of features (Stories)
'''Valuable''' – all Stories are connected directly to business value.
'''Estimable''' – the Team estimates the size of the Stories relative to each other.
'''Small''' – an important concept is raised here. Stories that are coming up in priority in the first or second Release should be small enough to be finished in one Sprint. Stories that are being implemented later can be large (Epics – more on this below).
'''Testable''' – knowing how we will know the Story is done, also called knowing the Definition of Done.

This review of the qualities of a good User Story gives some idea of the work to be done during Sprint Zero, while the User Stories are created, combined in one list, and then prioritized to make up the Product Backlog.

===Epic User Stories===

During Sprint Zero, the Product Owner will create a list of Epics. Epics are very large Stories. An example:
* As OSE, I want complete training materials in English for the 50 tools in GVCS on DVD, so that anyone with moderate experience in fabrication, and with access to the necessary tools and materials, can fabricate any of the 50 tools.

The list of Epics doesn't have to be exhaustive, but it should be thoroughly discussed and described, using the criteria for Stories developed in the video above.

===Moving on With Sprint Zero===

Here are some further questions to be taken up during Sprint Zero:
* Do we have the right people with the right skills? Is there a need for consultants, etc.?

* Given the Epics, the values, and the definitions of done, what sort of work place, tools and technology set up are indicated?

* What is the general approach we are taking? What will be the length of our Sprints? What is the Road Map -- the key release points? How many teams will there be? If there are multiple teams, how will the Scrum Masters and the Product Owners from the multiple teams work together?

At the end of Sprint Zero, the Product Backlog must contain enough prioritized Stories to fill at least the first Release. Ideally, there would be enough Stories for two or three releases, so that the broad outlines of the technology and personnel needed can be understood.

===Definition of Done===

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=9FnZsaRujpw&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
NOTE -- this video is LOUD!

Review of the main concepts of the video:

This video is from Agile; Scrum is one form of Agile. So in this video you don't see mention of a Scrum Master. Instead they talk about a Team Lead. However, the content on Definition of Done is relevant for OSE.

In this video he is discussing creating the Definition of Done at the Team level. The Product Owner needs to first supply the Team with an initial Definition of Done feature by feature. The Product Owner's Definition of Done revolves around the What (and explains the Why). The Team's Definition of Done defines the How.

In the video, he refers to "blockers," which are usually referred to in Scrum as Impediments. More on that later...

One value of this video is that it stresses how all members of a multi-functional Team get involved in creating the Definition of Done. It is crucial that this Definition is agreed to by everyone on the Team. When the Team commits to the work included in a Release, and in each Sprint, they are doing so based on the agreed on Definition of Done for each Story.

There is quite a bit of excess jargon in this video, but have patience, and relate it to GVCS. For example, we not only need to have the machine design "done," but also CAD drawings, an instructional video, and many other instructional components. Unifying the release and "done-ness" of all of these is what seems like the best, and most radical!, contribution Scrum can make to GVCS. These underlying points of “What is Done?” are crucial for us to understand the work that is needed in Sprint Zero.

==OSE [[GVCS]] Scrum==

Steps to take to convert OSE to Scrum:

1) Identify a Product Owner and Scrum Master
2) The Scrum Master helps the Product Owner identify the Stories and business values.
3) Decide whether to use collaborative online Scrum software (especially for the Product Backlog)
3) Decide who will participate in Sprint Zero, how long it will be, and the format.

First, we list the projects, in order of priority. See GVCS graphic on the right. Changes are: remove pyrolysis oil and [[Babington burner]] with biomass [[Pelletizer]] for fueling modern [[Steam Engine]]s. The burner is already present in the form of the [[:File:Gasifiericon.jpg|Gasifier Icon]]
[[Image:Slide1Linz7.jpg|thumb|40 [[GVCS]] technologies.]]
#CEB press - [[Full Product Release]] achieved.
#LifeTrac - on Prototype II
#Soil Pulverizer -

==See Also==

* [http://www.scrumhw.org/ Scrum for Hardware Product Development] ''Bringing Scrum to the Hardware Product Development Community''
* [http://maccherone.com/larry/2010/02/23/top-10-questions-when-using-agile-on-hardware-projects/ Top 10 questions when using Agile on hardware projects]

[[Category:Project Management]]

Scrum

2012-03-05T22:53:34Z

Mia Van Meter: /* Moving on With Sprint Zero */

Definition: '''[[wikipedia:Scrum (development)|Scrum]]''' is an iterative and incremental methodology for software projects and product- or application-development. It is also one of the variants of [[wikipedia:agile software development|agile software development]] methodologies.

==Why would a development team use Scrum?==

As demonstrated by high-powered software teams around the world, the Scrum process can increase a development team's efficiency dramatically. In recent years, some Scrum coaches (Scrum Masters) can consistently get development teams to be six times more efficient, and it is becoming almost unremarkable for a Scrum Master to kick a team into a productive state 15 times more productive than in their pre-Scrum days.

Scrum is essentially a double handful of rules for how a team should work together, and how they should be managed. Underneath those rules is a profound understanding of human nature. What motivates us? That is the essential question which Scrum answers. Scrum rules are designed to instill ownership, motivation, and creative problem-solving in team members. The dramatic results of a well-functioning Scrum team come from the synchronistic multiplying effect of a group of developers working “in the flow.” [http://en.wikipedia.org/wiki/Jeff_Sutherland/ Jeff Sutherland], one of the creators of Scrum, refers to these as “activated” teams.

Following [http://en.wikipedia.org/wiki/Lean_software_development/ Lean] development principles, the rules of Scrum are stripped down to the essentials. One of the implications of this is that teams must adopt all the Scrum rules in order to get Scrum results. Jeff Sutherland's favorite lecture topic seems to be “Scrumbutt.” This occurs when teams say, “Yes, we're doing Scrum, but...” and explain an aspect of Scrum they decided not to implement. According to Sutherland, you cannot get dramatic results unless you are pretty much a Scrum purist. That said, Scrum can “wrap around” other software development process technologies like, for example, XP or Lean. It's not essential to understand those technologies fully, for our purposes, but they are mentioned in the discussion on this page.

The most relevant question for a project like OSE is – is Scrum applicable outside the software development world? This is the answer that Joe Justice and the WikiSpeed team answer with a resounding “Yes!” In the 10-minute TEDX talk below, he explains briefly how the WikiSpeed Team, a collection of 44 volunteers in 4 countries, in three months used Scrum and associated processes to design and build a road-certifiable 4-person commuter car that can get over 100 miles per gallon in standard EPA road tests. The relevance of this to OSE is obvious – a distributed team of volunteers co-developing revolutionary hardware, sound familiar? It's well worth your while to spend a few hours absorbing the information on Scrum that this page points to, and to help explore its relevance for OSE in general, and the GVCS in particular.

In this video, Joe Justice, of WikiSpeed, explains the process his all-volunteer design team used to exceed expectations in their fuel-efficient car design.

<html><iframe width="300" height="182" src="http://www.youtube.com/watch?v=x8jdx-lf2Dw" frameborder="0" allowfullscreen></iframe></html>

.
.

.
.

==What is Scrum?==

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/watch?v=Q5k7a9YEoUI" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
The video above is a great first introduction to Scrum! It's fast paced, and the graphics easily convey the important information.

Of course, like any single Scrum coach, this one has his own take on Scrum, and in some instances it's likely that OSE Scrum will be different.

To review his core concepts:

Roles: Product Owner, Scrum Master, Team Members (developers, testers, customers)

Release Planning:
*Product Backlog– Estimate for each feature wanted in product.
*Release Backlog
*plan 4-12 Sprints – a substantive back log to a ship-ready state
*Sprint Backlog

Burndown Chart – day by day measure of the amount of work left in a Release, or Sprint

Bugs – have a separate Defect Backlog. Resolve bugs within the Sprint.

Daily Scrum – short, standing, identify bugs.

So that video is a great introduction to Scrum, but how would we actually get started?

The Scrum process starts with the Product Owner. They are responsible for creating the Product Backlog, creating the Development Team, and for providing the Team with the tools necessary for them to work. The Scrum Master helps the Product Owner with these tasks.

===Sprint ZERO===

To get ready for the first development Sprint, the Product Owner and the Scrum Master need to meet together, and with the Team, and do some initial preparation. The amount of time spent on Sprint Zero should be limited, and agreed upon in advance. Unfinished preparation can be added to the Product Backlog when Sprint Zero is finished. Additionally, the task of adding to the Product Backlog, and refining features that are down the road a bit, will be ongoing tasks for the Product Owner.

The most important outcome of Sprint Zero is to create understanding about the value of the work. Given that OSE might choose to have a team (Scrum) of Product Owners, it could make implementation more clear if the business values we are creating are explicitly ranked. Usually the process of identifying and clarifying the business value is held more distantly from the Team. In the case of OSE, it seems likely that a group of people will be determining the relative priorities of our business values, and the relative rankings of the features that we're planning on creating.

===User Stories===

We've been talking about ranking the features that make up the Product Backlog. In Scrum, these features are called Stories. There is an art to defining a Scrum Story, as you might imagine. Stories often take this form:

As _[User]_____, I want _[feature]_______, so that __[value]______.

An example:

* As a fabricator making a CNC Torch Table, I want complete and accurate CAD drawings, so that my efforts will result in a well-functioning machine.

Because the User is included in defining the feature, these are known as User Stories. The following video explains a good way to evaluate and improve User Stories, which are the list of features that make up the Product Backlog.

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=L_NyCczp0Fk&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.

To review the key ideas of the video:

'''Independent''' – dependencies among or between Stories need to be identified, eliminated, or tracked. An example of dependency: the training video for making a machine cannot be made until the machine is designed.
'''Negotiable''' – the Product Owner and the Team co-create the value and attributes of features (Stories)
'''Valuable''' – all Stories are connected directly to business value.
'''Estimable''' – the Team estimates the size of the Stories relative to each other.
'''Small''' – an important concept is raised here. Stories that are coming up in priority in the first or second Release should be small enough to be finished in one Sprint. Stories that are being implemented later can be large (Epics – more on this below).
'''Testable''' – knowing how we will know the Story is done, also called knowing the Definition of Done.

This review of the qualities of a good User Story gives some idea of the work to be done during Sprint Zero, while the User Stories are created, combined in one list, and then prioritized to make up the Product Backlog.

===Epic User Stories===

During Sprint Zero, the Product Owner will create a list of Epics. Epics are very large Stories. An example:
* As OSE, I want complete training materials in English for the 50 tools in GVCS on DVD, so that anyone with moderate experience in fabrication, and with access to the necessary tools and materials, can fabricate any of the 50 tools.

The list of Epics doesn't have to be exhaustive, but it should be thoroughly discussed and described, using the criteria for Stories developed in the video above.

===Moving on With Sprint Zero===

Here are some further questions to be taken up during Sprint Zero:
* Do we have the right people with the right skills? Is there a need for consultants, etc.?

* Given the Epics, the values, and the definitions of done, what sort of work place, tools and technology set up are indicated?

* What is the general approach we are taking? What will be the length of our Sprints? What is the Road Map -- the key release points? How many teams will there be? If there are multiple teams, how will the Scrum Masters and the Product Owners from the multiple teams work together?

At the end of Sprint Zero, the Product Backlog must contain enough prioritized Stories to fill at least the first Release. Ideally, there would be enough Stories for two or three releases, so that the broad outlines of the technology and personnel needed can be understood.

===Definition of Done===

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=9FnZsaRujpw&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
NOTE -- this video is LOUD!

Review of the main concepts of the video:

This video is from Agile; Scrum is one form of Agile. So in this video you don't see mention of a Scrum Master. Instead they talk about a Team Lead. However, the content on Definition of Done is relevant for OSE.

In this video he is discussing creating the Definition of Done at the Team level. The Product Owner needs to first supply the Team with an initial Definition of Done feature by feature. The Product Owner's Definition of Done revolves around the What (and explains the Why). The Team's Definition of Done defines the How.

In the video, he refers to "blockers," which are usually referred to in Scrum as Impediments. More on that later...

One value of this video is that it stresses how all members of a multi-functional Team get involved in creating the Definition of Done. It is crucial that this Definition is agreed to by everyone on the Team. When the Team commits to the work included in a Release, and in each Sprint, they are doing so based on the agreed on Definition of Done for each Story.

There is quite a bit of excess jargon in this video, but have patience, and relate it to GVCS. For example, we not only need to have the machine design "done," but also CAD drawings, an instructional video, and many other instructional components. Unifying the release and "done-ness" of all of these is what seems like the best, and most radical!, contribution Scrum can make to GVCS. These underlying points of “What is Done?” are crucial for us to understand the work that is needed in Sprint Zero.

==OSE [[GVCS]] Scrum==

Steps to take to convert OSE to Scrum:

1) Identify a Product Owner and Scrum Master
2) The Scrum Master helps the Product Owner identify the Stories and business values.
3) Decide whether to use collaborative online Scrum software (especially for the Product Backlog)
3) Decide who will participate in Sprint Zero, how long it will be, and the format.

First, we list the projects, in order of priority. See GVCS graphic on the right. Changes are: remove pyrolysis oil and [[Babington burner]] with biomass [[Pelletizer]] for fueling modern [[Steam Engine]]s. The burner is already present in the form of the [[:File:Gasifiericon.jpg|Gasifier Icon]]
[[Image:Slide1Linz7.jpg|thumb|40 [[GVCS]] technologies.]]
#CEB press - [[Full Product Release]] achieved.
#LifeTrac - on Prototype II
#Soil Pulverizer -

==See Also==

* [http://www.scrumhw.org/ Scrum for Hardware Product Development] ''Bringing Scrum to the Hardware Product Development Community''
* [http://maccherone.com/larry/2010/02/23/top-10-questions-when-using-agile-on-hardware-projects/ Top 10 questions when using Agile on hardware projects]

[[Category:Project Management]]

Scrum

2012-03-05T22:52:31Z

Mia Van Meter: /* Epic User Stories */

Definition: '''[[wikipedia:Scrum (development)|Scrum]]''' is an iterative and incremental methodology for software projects and product- or application-development. It is also one of the variants of [[wikipedia:agile software development|agile software development]] methodologies.

==Why would a development team use Scrum?==

As demonstrated by high-powered software teams around the world, the Scrum process can increase a development team's efficiency dramatically. In recent years, some Scrum coaches (Scrum Masters) can consistently get development teams to be six times more efficient, and it is becoming almost unremarkable for a Scrum Master to kick a team into a productive state 15 times more productive than in their pre-Scrum days.

Scrum is essentially a double handful of rules for how a team should work together, and how they should be managed. Underneath those rules is a profound understanding of human nature. What motivates us? That is the essential question which Scrum answers. Scrum rules are designed to instill ownership, motivation, and creative problem-solving in team members. The dramatic results of a well-functioning Scrum team come from the synchronistic multiplying effect of a group of developers working “in the flow.” [http://en.wikipedia.org/wiki/Jeff_Sutherland/ Jeff Sutherland], one of the creators of Scrum, refers to these as “activated” teams.

Following [http://en.wikipedia.org/wiki/Lean_software_development/ Lean] development principles, the rules of Scrum are stripped down to the essentials. One of the implications of this is that teams must adopt all the Scrum rules in order to get Scrum results. Jeff Sutherland's favorite lecture topic seems to be “Scrumbutt.” This occurs when teams say, “Yes, we're doing Scrum, but...” and explain an aspect of Scrum they decided not to implement. According to Sutherland, you cannot get dramatic results unless you are pretty much a Scrum purist. That said, Scrum can “wrap around” other software development process technologies like, for example, XP or Lean. It's not essential to understand those technologies fully, for our purposes, but they are mentioned in the discussion on this page.

The most relevant question for a project like OSE is – is Scrum applicable outside the software development world? This is the answer that Joe Justice and the WikiSpeed team answer with a resounding “Yes!” In the 10-minute TEDX talk below, he explains briefly how the WikiSpeed Team, a collection of 44 volunteers in 4 countries, in three months used Scrum and associated processes to design and build a road-certifiable 4-person commuter car that can get over 100 miles per gallon in standard EPA road tests. The relevance of this to OSE is obvious – a distributed team of volunteers co-developing revolutionary hardware, sound familiar? It's well worth your while to spend a few hours absorbing the information on Scrum that this page points to, and to help explore its relevance for OSE in general, and the GVCS in particular.

In this video, Joe Justice, of WikiSpeed, explains the process his all-volunteer design team used to exceed expectations in their fuel-efficient car design.

<html><iframe width="300" height="182" src="http://www.youtube.com/watch?v=x8jdx-lf2Dw" frameborder="0" allowfullscreen></iframe></html>

.
.

.
.

==What is Scrum?==

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/watch?v=Q5k7a9YEoUI" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
The video above is a great first introduction to Scrum! It's fast paced, and the graphics easily convey the important information.

Of course, like any single Scrum coach, this one has his own take on Scrum, and in some instances it's likely that OSE Scrum will be different.

To review his core concepts:

Roles: Product Owner, Scrum Master, Team Members (developers, testers, customers)

Release Planning:
*Product Backlog– Estimate for each feature wanted in product.
*Release Backlog
*plan 4-12 Sprints – a substantive back log to a ship-ready state
*Sprint Backlog

Burndown Chart – day by day measure of the amount of work left in a Release, or Sprint

Bugs – have a separate Defect Backlog. Resolve bugs within the Sprint.

Daily Scrum – short, standing, identify bugs.

So that video is a great introduction to Scrum, but how would we actually get started?

The Scrum process starts with the Product Owner. They are responsible for creating the Product Backlog, creating the Development Team, and for providing the Team with the tools necessary for them to work. The Scrum Master helps the Product Owner with these tasks.

===Sprint ZERO===

To get ready for the first development Sprint, the Product Owner and the Scrum Master need to meet together, and with the Team, and do some initial preparation. The amount of time spent on Sprint Zero should be limited, and agreed upon in advance. Unfinished preparation can be added to the Product Backlog when Sprint Zero is finished. Additionally, the task of adding to the Product Backlog, and refining features that are down the road a bit, will be ongoing tasks for the Product Owner.

The most important outcome of Sprint Zero is to create understanding about the value of the work. Given that OSE might choose to have a team (Scrum) of Product Owners, it could make implementation more clear if the business values we are creating are explicitly ranked. Usually the process of identifying and clarifying the business value is held more distantly from the Team. In the case of OSE, it seems likely that a group of people will be determining the relative priorities of our business values, and the relative rankings of the features that we're planning on creating.

===User Stories===

We've been talking about ranking the features that make up the Product Backlog. In Scrum, these features are called Stories. There is an art to defining a Scrum Story, as you might imagine. Stories often take this form:

As _[User]_____, I want _[feature]_______, so that __[value]______.

An example:

* As a fabricator making a CNC Torch Table, I want complete and accurate CAD drawings, so that my efforts will result in a well-functioning machine.

Because the User is included in defining the feature, these are known as User Stories. The following video explains a good way to evaluate and improve User Stories, which are the list of features that make up the Product Backlog.

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=L_NyCczp0Fk&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.

To review the key ideas of the video:

'''Independent''' – dependencies among or between Stories need to be identified, eliminated, or tracked. An example of dependency: the training video for making a machine cannot be made until the machine is designed.
'''Negotiable''' – the Product Owner and the Team co-create the value and attributes of features (Stories)
'''Valuable''' – all Stories are connected directly to business value.
'''Estimable''' – the Team estimates the size of the Stories relative to each other.
'''Small''' – an important concept is raised here. Stories that are coming up in priority in the first or second Release should be small enough to be finished in one Sprint. Stories that are being implemented later can be large (Epics – more on this below).
'''Testable''' – knowing how we will know the Story is done, also called knowing the Definition of Done.

This review of the qualities of a good User Story gives some idea of the work to be done during Sprint Zero, while the User Stories are created, combined in one list, and then prioritized to make up the Product Backlog.

===Epic User Stories===

During Sprint Zero, the Product Owner will create a list of Epics. Epics are very large Stories. An example:
* As OSE, I want complete training materials in English for the 50 tools in GVCS on DVD, so that anyone with moderate experience in fabrication, and with access to the necessary tools and materials, can fabricate any of the 50 tools.

The list of Epics doesn't have to be exhaustive, but it should be thoroughly discussed and described, using the criteria for Stories developed in the video above.

===Moving on With Sprint Zero===

Here are some further questions to be taken up during Sprint Zero:
* Do we have the right people with the right skills? Is there a need for consultants, etc.?

* Given the Epics, the values, and the definitions of done, what sort of work place, tools and technology set up are indicated?

* What is the general approach we are taking? What will be the length of our Sprints? What is the Road Map -- the key release points? How many teams will there be? If there are multiple teams, how will the Scrum Masters and the Product Owners from the multiple teams work together?

At the end of Sprint Zero, the Product Backlog must contain enough prioritized Stories to fill at least the first Release. Ideally, there would be enough Stories for two or three releases, so that the broad outlines of the technology and personnel needed can be understood.

Here's a possible outline for Sprint Zero:
Describe final product
Create a team(s) workspace(s)
Determine the length of sprints
Identify business value (the criteria to measure the value of work as it's done)
Create epics. Prioritize epics (consider relative business value)
For the highest priority epic, turn the epic into stories
Prioritize the stories (consider relative business value)
For each story, create a definition of done

===Definition of Done===

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=9FnZsaRujpw&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
NOTE -- this video is LOUD!

Review of the main concepts of the video:

This video is from Agile; Scrum is one form of Agile. So in this video you don't see mention of a Scrum Master. Instead they talk about a Team Lead. However, the content on Definition of Done is relevant for OSE.

In this video he is discussing creating the Definition of Done at the Team level. The Product Owner needs to first supply the Team with an initial Definition of Done feature by feature. The Product Owner's Definition of Done revolves around the What (and explains the Why). The Team's Definition of Done defines the How.

In the video, he refers to "blockers," which are usually referred to in Scrum as Impediments. More on that later...

One value of this video is that it stresses how all members of a multi-functional Team get involved in creating the Definition of Done. It is crucial that this Definition is agreed to by everyone on the Team. When the Team commits to the work included in a Release, and in each Sprint, they are doing so based on the agreed on Definition of Done for each Story.

There is quite a bit of excess jargon in this video, but have patience, and relate it to GVCS. For example, we not only need to have the machine design "done," but also CAD drawings, an instructional video, and many other instructional components. Unifying the release and "done-ness" of all of these is what seems like the best, and most radical!, contribution Scrum can make to GVCS. These underlying points of “What is Done?” are crucial for us to understand the work that is needed in Sprint Zero.

==OSE [[GVCS]] Scrum==

Steps to take to convert OSE to Scrum:

1) Identify a Product Owner and Scrum Master
2) The Scrum Master helps the Product Owner identify the Stories and business values.
3) Decide whether to use collaborative online Scrum software (especially for the Product Backlog)
3) Decide who will participate in Sprint Zero, how long it will be, and the format.

First, we list the projects, in order of priority. See GVCS graphic on the right. Changes are: remove pyrolysis oil and [[Babington burner]] with biomass [[Pelletizer]] for fueling modern [[Steam Engine]]s. The burner is already present in the form of the [[:File:Gasifiericon.jpg|Gasifier Icon]]
[[Image:Slide1Linz7.jpg|thumb|40 [[GVCS]] technologies.]]
#CEB press - [[Full Product Release]] achieved.
#LifeTrac - on Prototype II
#Soil Pulverizer -

==See Also==

* [http://www.scrumhw.org/ Scrum for Hardware Product Development] ''Bringing Scrum to the Hardware Product Development Community''
* [http://maccherone.com/larry/2010/02/23/top-10-questions-when-using-agile-on-hardware-projects/ Top 10 questions when using Agile on hardware projects]

[[Category:Project Management]]

Scrum

2012-03-05T22:51:37Z

Mia Van Meter: /* Sprint ZERO */

Definition: '''[[wikipedia:Scrum (development)|Scrum]]''' is an iterative and incremental methodology for software projects and product- or application-development. It is also one of the variants of [[wikipedia:agile software development|agile software development]] methodologies.

==Why would a development team use Scrum?==

As demonstrated by high-powered software teams around the world, the Scrum process can increase a development team's efficiency dramatically. In recent years, some Scrum coaches (Scrum Masters) can consistently get development teams to be six times more efficient, and it is becoming almost unremarkable for a Scrum Master to kick a team into a productive state 15 times more productive than in their pre-Scrum days.

Scrum is essentially a double handful of rules for how a team should work together, and how they should be managed. Underneath those rules is a profound understanding of human nature. What motivates us? That is the essential question which Scrum answers. Scrum rules are designed to instill ownership, motivation, and creative problem-solving in team members. The dramatic results of a well-functioning Scrum team come from the synchronistic multiplying effect of a group of developers working “in the flow.” [http://en.wikipedia.org/wiki/Jeff_Sutherland/ Jeff Sutherland], one of the creators of Scrum, refers to these as “activated” teams.

Following [http://en.wikipedia.org/wiki/Lean_software_development/ Lean] development principles, the rules of Scrum are stripped down to the essentials. One of the implications of this is that teams must adopt all the Scrum rules in order to get Scrum results. Jeff Sutherland's favorite lecture topic seems to be “Scrumbutt.” This occurs when teams say, “Yes, we're doing Scrum, but...” and explain an aspect of Scrum they decided not to implement. According to Sutherland, you cannot get dramatic results unless you are pretty much a Scrum purist. That said, Scrum can “wrap around” other software development process technologies like, for example, XP or Lean. It's not essential to understand those technologies fully, for our purposes, but they are mentioned in the discussion on this page.

The most relevant question for a project like OSE is – is Scrum applicable outside the software development world? This is the answer that Joe Justice and the WikiSpeed team answer with a resounding “Yes!” In the 10-minute TEDX talk below, he explains briefly how the WikiSpeed Team, a collection of 44 volunteers in 4 countries, in three months used Scrum and associated processes to design and build a road-certifiable 4-person commuter car that can get over 100 miles per gallon in standard EPA road tests. The relevance of this to OSE is obvious – a distributed team of volunteers co-developing revolutionary hardware, sound familiar? It's well worth your while to spend a few hours absorbing the information on Scrum that this page points to, and to help explore its relevance for OSE in general, and the GVCS in particular.

In this video, Joe Justice, of WikiSpeed, explains the process his all-volunteer design team used to exceed expectations in their fuel-efficient car design.

<html><iframe width="300" height="182" src="http://www.youtube.com/watch?v=x8jdx-lf2Dw" frameborder="0" allowfullscreen></iframe></html>

.
.

.
.

==What is Scrum?==

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/watch?v=Q5k7a9YEoUI" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
The video above is a great first introduction to Scrum! It's fast paced, and the graphics easily convey the important information.

Of course, like any single Scrum coach, this one has his own take on Scrum, and in some instances it's likely that OSE Scrum will be different.

To review his core concepts:

Roles: Product Owner, Scrum Master, Team Members (developers, testers, customers)

Release Planning:
*Product Backlog– Estimate for each feature wanted in product.
*Release Backlog
*plan 4-12 Sprints – a substantive back log to a ship-ready state
*Sprint Backlog

Burndown Chart – day by day measure of the amount of work left in a Release, or Sprint

Bugs – have a separate Defect Backlog. Resolve bugs within the Sprint.

Daily Scrum – short, standing, identify bugs.

So that video is a great introduction to Scrum, but how would we actually get started?

The Scrum process starts with the Product Owner. They are responsible for creating the Product Backlog, creating the Development Team, and for providing the Team with the tools necessary for them to work. The Scrum Master helps the Product Owner with these tasks.

===Sprint ZERO===

To get ready for the first development Sprint, the Product Owner and the Scrum Master need to meet together, and with the Team, and do some initial preparation. The amount of time spent on Sprint Zero should be limited, and agreed upon in advance. Unfinished preparation can be added to the Product Backlog when Sprint Zero is finished. Additionally, the task of adding to the Product Backlog, and refining features that are down the road a bit, will be ongoing tasks for the Product Owner.

The most important outcome of Sprint Zero is to create understanding about the value of the work. Given that OSE might choose to have a team (Scrum) of Product Owners, it could make implementation more clear if the business values we are creating are explicitly ranked. Usually the process of identifying and clarifying the business value is held more distantly from the Team. In the case of OSE, it seems likely that a group of people will be determining the relative priorities of our business values, and the relative rankings of the features that we're planning on creating.

===User Stories===

We've been talking about ranking the features that make up the Product Backlog. In Scrum, these features are called Stories. There is an art to defining a Scrum Story, as you might imagine. Stories often take this form:

As _[User]_____, I want _[feature]_______, so that __[value]______.

An example:

* As a fabricator making a CNC Torch Table, I want complete and accurate CAD drawings, so that my efforts will result in a well-functioning machine.

Because the User is included in defining the feature, these are known as User Stories. The following video explains a good way to evaluate and improve User Stories, which are the list of features that make up the Product Backlog.

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=L_NyCczp0Fk&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.

To review the key ideas of the video:

'''Independent''' – dependencies among or between Stories need to be identified, eliminated, or tracked. An example of dependency: the training video for making a machine cannot be made until the machine is designed.
'''Negotiable''' – the Product Owner and the Team co-create the value and attributes of features (Stories)
'''Valuable''' – all Stories are connected directly to business value.
'''Estimable''' – the Team estimates the size of the Stories relative to each other.
'''Small''' – an important concept is raised here. Stories that are coming up in priority in the first or second Release should be small enough to be finished in one Sprint. Stories that are being implemented later can be large (Epics – more on this below).
'''Testable''' – knowing how we will know the Story is done, also called knowing the Definition of Done.

This review of the qualities of a good User Story gives some idea of the work to be done during Sprint Zero, while the User Stories are created, combined in one list, and then prioritized to make up the Product Backlog.

===Epic User Stories===

During Sprint Zero, the Product Owner will create a list of Epics. Epics are very large Stories. An example:
* As OSE, I want complete training materials in English for the 50 tools in GVCS on DVD, so that anyone with moderate experience in fabrication, and with access to the necessary tools and materials, can fabricate any of the 50 tools.

The list of Epics doesn't have to be exhaustive, but it should be thoroughly discussed and described, using the criteria for Stories developed in the video above.

Here are some further questions to be taken up during Sprint Zero:
* Do we have the right people with the right skills? Is there a need for consultants, etc.?

* Given the Epics, the values, and the definitions of done, what sort of work place, tools and technology set up are indicated?

* What is the general approach we are taking? What will be the length of our Sprints? What is the Road Map -- the key release points? How many teams will there be? If there are multiple teams, how will the Scrum Masters and the Product Owners from the multiple teams work together?

At the end of Sprint Zero, the Product Backlog must contain enough prioritized Stories to fill at least the first Release. Ideally, there would be enough Stories for two or three releases, so that the broad outlines of the technology and personnel needed can be understood.

Here's a possible outline for Sprint Zero:
Describe final product
Create a team(s) workspace(s)
Determine the length of sprints
Identify business value (the criteria to measure the value of work as it's done)
Create epics. Prioritize epics (consider relative business value)
For the highest priority epic, turn the epic into stories
Prioritize the stories (consider relative business value)
For each story, create a definition of done

===Definition of Done===

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=9FnZsaRujpw&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
NOTE -- this video is LOUD!

Review of the main concepts of the video:

This video is from Agile; Scrum is one form of Agile. So in this video you don't see mention of a Scrum Master. Instead they talk about a Team Lead. However, the content on Definition of Done is relevant for OSE.

In this video he is discussing creating the Definition of Done at the Team level. The Product Owner needs to first supply the Team with an initial Definition of Done feature by feature. The Product Owner's Definition of Done revolves around the What (and explains the Why). The Team's Definition of Done defines the How.

In the video, he refers to "blockers," which are usually referred to in Scrum as Impediments. More on that later...

One value of this video is that it stresses how all members of a multi-functional Team get involved in creating the Definition of Done. It is crucial that this Definition is agreed to by everyone on the Team. When the Team commits to the work included in a Release, and in each Sprint, they are doing so based on the agreed on Definition of Done for each Story.

There is quite a bit of excess jargon in this video, but have patience, and relate it to GVCS. For example, we not only need to have the machine design "done," but also CAD drawings, an instructional video, and many other instructional components. Unifying the release and "done-ness" of all of these is what seems like the best, and most radical!, contribution Scrum can make to GVCS. These underlying points of “What is Done?” are crucial for us to understand the work that is needed in Sprint Zero.

==OSE [[GVCS]] Scrum==

Steps to take to convert OSE to Scrum:

1) Identify a Product Owner and Scrum Master
2) The Scrum Master helps the Product Owner identify the Stories and business values.
3) Decide whether to use collaborative online Scrum software (especially for the Product Backlog)
3) Decide who will participate in Sprint Zero, how long it will be, and the format.

First, we list the projects, in order of priority. See GVCS graphic on the right. Changes are: remove pyrolysis oil and [[Babington burner]] with biomass [[Pelletizer]] for fueling modern [[Steam Engine]]s. The burner is already present in the form of the [[:File:Gasifiericon.jpg|Gasifier Icon]]
[[Image:Slide1Linz7.jpg|thumb|40 [[GVCS]] technologies.]]
#CEB press - [[Full Product Release]] achieved.
#LifeTrac - on Prototype II
#Soil Pulverizer -

==See Also==

* [http://www.scrumhw.org/ Scrum for Hardware Product Development] ''Bringing Scrum to the Hardware Product Development Community''
* [http://maccherone.com/larry/2010/02/23/top-10-questions-when-using-agile-on-hardware-projects/ Top 10 questions when using Agile on hardware projects]

[[Category:Project Management]]

Scrum

2012-03-05T22:51:00Z

Mia Van Meter: /* User Stories */

Definition: '''[[wikipedia:Scrum (development)|Scrum]]''' is an iterative and incremental methodology for software projects and product- or application-development. It is also one of the variants of [[wikipedia:agile software development|agile software development]] methodologies.

==Why would a development team use Scrum?==

As demonstrated by high-powered software teams around the world, the Scrum process can increase a development team's efficiency dramatically. In recent years, some Scrum coaches (Scrum Masters) can consistently get development teams to be six times more efficient, and it is becoming almost unremarkable for a Scrum Master to kick a team into a productive state 15 times more productive than in their pre-Scrum days.

Scrum is essentially a double handful of rules for how a team should work together, and how they should be managed. Underneath those rules is a profound understanding of human nature. What motivates us? That is the essential question which Scrum answers. Scrum rules are designed to instill ownership, motivation, and creative problem-solving in team members. The dramatic results of a well-functioning Scrum team come from the synchronistic multiplying effect of a group of developers working “in the flow.” [http://en.wikipedia.org/wiki/Jeff_Sutherland/ Jeff Sutherland], one of the creators of Scrum, refers to these as “activated” teams.

Following [http://en.wikipedia.org/wiki/Lean_software_development/ Lean] development principles, the rules of Scrum are stripped down to the essentials. One of the implications of this is that teams must adopt all the Scrum rules in order to get Scrum results. Jeff Sutherland's favorite lecture topic seems to be “Scrumbutt.” This occurs when teams say, “Yes, we're doing Scrum, but...” and explain an aspect of Scrum they decided not to implement. According to Sutherland, you cannot get dramatic results unless you are pretty much a Scrum purist. That said, Scrum can “wrap around” other software development process technologies like, for example, XP or Lean. It's not essential to understand those technologies fully, for our purposes, but they are mentioned in the discussion on this page.

The most relevant question for a project like OSE is – is Scrum applicable outside the software development world? This is the answer that Joe Justice and the WikiSpeed team answer with a resounding “Yes!” In the 10-minute TEDX talk below, he explains briefly how the WikiSpeed Team, a collection of 44 volunteers in 4 countries, in three months used Scrum and associated processes to design and build a road-certifiable 4-person commuter car that can get over 100 miles per gallon in standard EPA road tests. The relevance of this to OSE is obvious – a distributed team of volunteers co-developing revolutionary hardware, sound familiar? It's well worth your while to spend a few hours absorbing the information on Scrum that this page points to, and to help explore its relevance for OSE in general, and the GVCS in particular.

In this video, Joe Justice, of WikiSpeed, explains the process his all-volunteer design team used to exceed expectations in their fuel-efficient car design.

<html><iframe width="300" height="182" src="http://www.youtube.com/watch?v=x8jdx-lf2Dw" frameborder="0" allowfullscreen></iframe></html>

.
.

.
.

==What is Scrum?==

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/watch?v=Q5k7a9YEoUI" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
The video above is a great first introduction to Scrum! It's fast paced, and the graphics easily convey the important information.

Of course, like any single Scrum coach, this one has his own take on Scrum, and in some instances it's likely that OSE Scrum will be different.

To review his core concepts:

Roles: Product Owner, Scrum Master, Team Members (developers, testers, customers)

Release Planning:
*Product Backlog– Estimate for each feature wanted in product.
*Release Backlog
*plan 4-12 Sprints – a substantive back log to a ship-ready state
*Sprint Backlog

Burndown Chart – day by day measure of the amount of work left in a Release, or Sprint

Bugs – have a separate Defect Backlog. Resolve bugs within the Sprint.

Daily Scrum – short, standing, identify bugs.

So that video is a great introduction to Scrum, but how would we actually get started?

The Scrum process starts with the Product Owner. They are responsible for creating the Product Backlog, creating the Development Team, and for providing the Team with the tools necessary for them to work. The Scrum Master helps the Product Owner with these tasks.

===Sprint ZERO===

To get ready for the first development Sprint, the Product Owner and the Scrum Master need to meet together, and with the Team, and do some initial preparation. The amount of time spent on Sprint Zero should be limited, and agreed upon in advance. Unfinished preparation can be added to the Product Backlog when Sprint Zero is finished. Additionally, the task of adding to the Product Backlog, and refining features that are down the road a bit, will be ongoing tasks for the Product Owner.

The most important outcome of Sprint Zero is to create understanding about the value of the work. Given that OSE might choose to have a team (Scrum) of Product Owners, it could make implementation more clear if the business values we are creating are explicitly ranked. Usually the process of identifying and clarifying the business value is held more distantly from the Team. In the case of OSE, it seems likely that a group of people will be determining the relative priorities of our business values, and the relative rankings of the features that we're planning on creating.

http://opensourceecology.org/w/index.php?title=Scrum&action=edit&section=5

We've been talking about ranking the features that make up the Product Backlog. In Scrum, these features are called Stories. There is an art to defining a Scrum Story, as you might imagine. Stories often take this form:

As _[User]_____, I want _[feature]_______, so that __[value]______.

An example:

* As a fabricator making a CNC Torch Table, I want complete and accurate CAD drawings, so that my efforts will result in a well-functioning machine.

Because the User is included in defining the feature, these are known as User Stories. The following video explains a good way to evaluate and improve User Stories, which are the list of features that make up the Product Backlog.

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=L_NyCczp0Fk&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.

To review the key ideas of the video:

'''Independent''' – dependencies among or between Stories need to be identified, eliminated, or tracked. An example of dependency: the training video for making a machine cannot be made until the machine is designed.
'''Negotiable''' – the Product Owner and the Team co-create the value and attributes of features (Stories)
'''Valuable''' – all Stories are connected directly to business value.
'''Estimable''' – the Team estimates the size of the Stories relative to each other.
'''Small''' – an important concept is raised here. Stories that are coming up in priority in the first or second Release should be small enough to be finished in one Sprint. Stories that are being implemented later can be large (Epics – more on this below).
'''Testable''' – knowing how we will know the Story is done, also called knowing the Definition of Done.

This review of the qualities of a good User Story gives some idea of the work to be done during Sprint Zero, while the User Stories are created, combined in one list, and then prioritized to make up the Product Backlog.

===Epic User Stories===

During Sprint Zero, the Product Owner will create a list of Epics. Epics are very large Stories. An example:
* As OSE, I want complete training materials in English for the 50 tools in GVCS on DVD, so that anyone with moderate experience in fabrication, and with access to the necessary tools and materials, can fabricate any of the 50 tools.

The list of Epics doesn't have to be exhaustive, but it should be thoroughly discussed and described, using the criteria for Stories developed in the video above.

Here are some further questions to be taken up during Sprint Zero:
* Do we have the right people with the right skills? Is there a need for consultants, etc.?

* Given the Epics, the values, and the definitions of done, what sort of work place, tools and technology set up are indicated?

* What is the general approach we are taking? What will be the length of our Sprints? What is the Road Map -- the key release points? How many teams will there be? If there are multiple teams, how will the Scrum Masters and the Product Owners from the multiple teams work together?

At the end of Sprint Zero, the Product Backlog must contain enough prioritized Stories to fill at least the first Release. Ideally, there would be enough Stories for two or three releases, so that the broad outlines of the technology and personnel needed can be understood.

Here's a possible outline for Sprint Zero:
Describe final product
Create a team(s) workspace(s)
Determine the length of sprints
Identify business value (the criteria to measure the value of work as it's done)
Create epics. Prioritize epics (consider relative business value)
For the highest priority epic, turn the epic into stories
Prioritize the stories (consider relative business value)
For each story, create a definition of done

===Definition of Done===

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=9FnZsaRujpw&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
NOTE -- this video is LOUD!

Review of the main concepts of the video:

This video is from Agile; Scrum is one form of Agile. So in this video you don't see mention of a Scrum Master. Instead they talk about a Team Lead. However, the content on Definition of Done is relevant for OSE.

In this video he is discussing creating the Definition of Done at the Team level. The Product Owner needs to first supply the Team with an initial Definition of Done feature by feature. The Product Owner's Definition of Done revolves around the What (and explains the Why). The Team's Definition of Done defines the How.

In the video, he refers to "blockers," which are usually referred to in Scrum as Impediments. More on that later...

One value of this video is that it stresses how all members of a multi-functional Team get involved in creating the Definition of Done. It is crucial that this Definition is agreed to by everyone on the Team. When the Team commits to the work included in a Release, and in each Sprint, they are doing so based on the agreed on Definition of Done for each Story.

There is quite a bit of excess jargon in this video, but have patience, and relate it to GVCS. For example, we not only need to have the machine design "done," but also CAD drawings, an instructional video, and many other instructional components. Unifying the release and "done-ness" of all of these is what seems like the best, and most radical!, contribution Scrum can make to GVCS. These underlying points of “What is Done?” are crucial for us to understand the work that is needed in Sprint Zero.

==OSE [[GVCS]] Scrum==

Steps to take to convert OSE to Scrum:

1) Identify a Product Owner and Scrum Master
2) The Scrum Master helps the Product Owner identify the Stories and business values.
3) Decide whether to use collaborative online Scrum software (especially for the Product Backlog)
3) Decide who will participate in Sprint Zero, how long it will be, and the format.

First, we list the projects, in order of priority. See GVCS graphic on the right. Changes are: remove pyrolysis oil and [[Babington burner]] with biomass [[Pelletizer]] for fueling modern [[Steam Engine]]s. The burner is already present in the form of the [[:File:Gasifiericon.jpg|Gasifier Icon]]
[[Image:Slide1Linz7.jpg|thumb|40 [[GVCS]] technologies.]]
#CEB press - [[Full Product Release]] achieved.
#LifeTrac - on Prototype II
#Soil Pulverizer -

==See Also==

* [http://www.scrumhw.org/ Scrum for Hardware Product Development] ''Bringing Scrum to the Hardware Product Development Community''
* [http://maccherone.com/larry/2010/02/23/top-10-questions-when-using-agile-on-hardware-projects/ Top 10 questions when using Agile on hardware projects]

[[Category:Project Management]]

Scrum

2012-03-05T22:49:49Z

Mia Van Meter: /* Sprint ZERO */

Definition: '''[[wikipedia:Scrum (development)|Scrum]]''' is an iterative and incremental methodology for software projects and product- or application-development. It is also one of the variants of [[wikipedia:agile software development|agile software development]] methodologies.

==Why would a development team use Scrum?==

As demonstrated by high-powered software teams around the world, the Scrum process can increase a development team's efficiency dramatically. In recent years, some Scrum coaches (Scrum Masters) can consistently get development teams to be six times more efficient, and it is becoming almost unremarkable for a Scrum Master to kick a team into a productive state 15 times more productive than in their pre-Scrum days.

Scrum is essentially a double handful of rules for how a team should work together, and how they should be managed. Underneath those rules is a profound understanding of human nature. What motivates us? That is the essential question which Scrum answers. Scrum rules are designed to instill ownership, motivation, and creative problem-solving in team members. The dramatic results of a well-functioning Scrum team come from the synchronistic multiplying effect of a group of developers working “in the flow.” [http://en.wikipedia.org/wiki/Jeff_Sutherland/ Jeff Sutherland], one of the creators of Scrum, refers to these as “activated” teams.

Following [http://en.wikipedia.org/wiki/Lean_software_development/ Lean] development principles, the rules of Scrum are stripped down to the essentials. One of the implications of this is that teams must adopt all the Scrum rules in order to get Scrum results. Jeff Sutherland's favorite lecture topic seems to be “Scrumbutt.” This occurs when teams say, “Yes, we're doing Scrum, but...” and explain an aspect of Scrum they decided not to implement. According to Sutherland, you cannot get dramatic results unless you are pretty much a Scrum purist. That said, Scrum can “wrap around” other software development process technologies like, for example, XP or Lean. It's not essential to understand those technologies fully, for our purposes, but they are mentioned in the discussion on this page.

The most relevant question for a project like OSE is – is Scrum applicable outside the software development world? This is the answer that Joe Justice and the WikiSpeed team answer with a resounding “Yes!” In the 10-minute TEDX talk below, he explains briefly how the WikiSpeed Team, a collection of 44 volunteers in 4 countries, in three months used Scrum and associated processes to design and build a road-certifiable 4-person commuter car that can get over 100 miles per gallon in standard EPA road tests. The relevance of this to OSE is obvious – a distributed team of volunteers co-developing revolutionary hardware, sound familiar? It's well worth your while to spend a few hours absorbing the information on Scrum that this page points to, and to help explore its relevance for OSE in general, and the GVCS in particular.

In this video, Joe Justice, of WikiSpeed, explains the process his all-volunteer design team used to exceed expectations in their fuel-efficient car design.

<html><iframe width="300" height="182" src="http://www.youtube.com/watch?v=x8jdx-lf2Dw" frameborder="0" allowfullscreen></iframe></html>

.
.

.
.

==What is Scrum?==

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/watch?v=Q5k7a9YEoUI" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
The video above is a great first introduction to Scrum! It's fast paced, and the graphics easily convey the important information.

Of course, like any single Scrum coach, this one has his own take on Scrum, and in some instances it's likely that OSE Scrum will be different.

To review his core concepts:

Roles: Product Owner, Scrum Master, Team Members (developers, testers, customers)

Release Planning:
*Product Backlog– Estimate for each feature wanted in product.
*Release Backlog
*plan 4-12 Sprints – a substantive back log to a ship-ready state
*Sprint Backlog

Burndown Chart – day by day measure of the amount of work left in a Release, or Sprint

Bugs – have a separate Defect Backlog. Resolve bugs within the Sprint.

Daily Scrum – short, standing, identify bugs.

So that video is a great introduction to Scrum, but how would we actually get started?

The Scrum process starts with the Product Owner. They are responsible for creating the Product Backlog, creating the Development Team, and for providing the Team with the tools necessary for them to work. The Scrum Master helps the Product Owner with these tasks.

===Sprint ZERO===

To get ready for the first development Sprint, the Product Owner and the Scrum Master need to meet together, and with the Team, and do some initial preparation. The amount of time spent on Sprint Zero should be limited, and agreed upon in advance. Unfinished preparation can be added to the Product Backlog when Sprint Zero is finished. Additionally, the task of adding to the Product Backlog, and refining features that are down the road a bit, will be ongoing tasks for the Product Owner.

The most important outcome of Sprint Zero is to create understanding about the value of the work. Given that OSE might choose to have a team (Scrum) of Product Owners, it could make implementation more clear if the business values we are creating are explicitly ranked. Usually the process of identifying and clarifying the business value is held more distantly from the Team. In the case of OSE, it seems likely that a group of people will be determining the relative priorities of our business values, and the relative rankings of the features that we're planning on creating.

====User Stories====

We've been talking about ranking the features that make up the Product Backlog. In Scrum, these features are called Stories. There is an art to defining a Scrum Story, as you might imagine. Stories often take this form:

As _[User]_____, I want _[feature]_______, so that __[value]______.

An example:

* As a fabricator making a CNC Torch Table, I want complete and accurate CAD drawings, so that my efforts will result in a well-functioning machine.

Because the User is included in defining the feature, these are known as User Stories. The following video explains a good way to evaluate and improve User Stories, which are the list of features that make up the Product Backlog.

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=L_NyCczp0Fk&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.

To review the key ideas of the video:

'''Independent''' – dependencies among or between Stories need to be identified, eliminated, or tracked. An example of dependency: the training video for making a machine cannot be made until the machine is designed.
'''Negotiable''' – the Product Owner and the Team co-create the value and attributes of features (Stories)
'''Valuable''' – all Stories are connected directly to business value.
'''Estimable''' – the Team estimates the size of the Stories relative to each other.
'''Small''' – an important concept is raised here. Stories that are coming up in priority in the first or second Release should be small enough to be finished in one Sprint. Stories that are being implemented later can be large (Epics – more on this below).
'''Testable''' – knowing how we will know the Story is done, also called knowing the Definition of Done.

This review of the qualities of a good User Story gives some idea of the work to be done during Sprint Zero, while the User Stories are created, combined in one list, and then prioritized to make up the Product Backlog.

During Sprint Zero, the Product Owner will create a list of Epics. Epics are very large Stories. An example:
* As OSE, I want complete training materials in English for the 50 tools in GVCS on DVD, so that anyone with moderate experience in fabrication, and with access to the necessary tools and materials, can fabricate any of the 50 tools.

The list of Epics doesn't have to be exhaustive, but it should be thoroughly discussed and described, using the criteria for Stories developed in the video above.

Here are some further questions to be taken up during Sprint Zero:
* Do we have the right people with the right skills? Is there a need for consultants, etc.?

* Given the Epics, the values, and the definitions of done, what sort of work place, tools and technology set up are indicated?

* What is the general approach we are taking? What will be the length of our Sprints? What is the Road Map -- the key release points? How many teams will there be? If there are multiple teams, how will the Scrum Masters and the Product Owners from the multiple teams work together?

At the end of Sprint Zero, the Product Backlog must contain enough prioritized Stories to fill at least the first Release. Ideally, there would be enough Stories for two or three releases, so that the broad outlines of the technology and personnel needed can be understood.

Here's a possible outline for Sprint Zero:
Describe final product
Create a team(s) workspace(s)
Determine the length of sprints
Identify business value (the criteria to measure the value of work as it's done)
Create epics. Prioritize epics (consider relative business value)
For the highest priority epic, turn the epic into stories
Prioritize the stories (consider relative business value)
For each story, create a definition of done

===Definition of Done===

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=9FnZsaRujpw&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
NOTE -- this video is LOUD!

Review of the main concepts of the video:

This video is from Agile; Scrum is one form of Agile. So in this video you don't see mention of a Scrum Master. Instead they talk about a Team Lead. However, the content on Definition of Done is relevant for OSE.

In this video he is discussing creating the Definition of Done at the Team level. The Product Owner needs to first supply the Team with an initial Definition of Done feature by feature. The Product Owner's Definition of Done revolves around the What (and explains the Why). The Team's Definition of Done defines the How.

In the video, he refers to "blockers," which are usually referred to in Scrum as Impediments. More on that later...

One value of this video is that it stresses how all members of a multi-functional Team get involved in creating the Definition of Done. It is crucial that this Definition is agreed to by everyone on the Team. When the Team commits to the work included in a Release, and in each Sprint, they are doing so based on the agreed on Definition of Done for each Story.

There is quite a bit of excess jargon in this video, but have patience, and relate it to GVCS. For example, we not only need to have the machine design "done," but also CAD drawings, an instructional video, and many other instructional components. Unifying the release and "done-ness" of all of these is what seems like the best, and most radical!, contribution Scrum can make to GVCS. These underlying points of “What is Done?” are crucial for us to understand the work that is needed in Sprint Zero.

==OSE [[GVCS]] Scrum==

Steps to take to convert OSE to Scrum:

1) Identify a Product Owner and Scrum Master
2) The Scrum Master helps the Product Owner identify the Stories and business values.
3) Decide whether to use collaborative online Scrum software (especially for the Product Backlog)
3) Decide who will participate in Sprint Zero, how long it will be, and the format.

First, we list the projects, in order of priority. See GVCS graphic on the right. Changes are: remove pyrolysis oil and [[Babington burner]] with biomass [[Pelletizer]] for fueling modern [[Steam Engine]]s. The burner is already present in the form of the [[:File:Gasifiericon.jpg|Gasifier Icon]]
[[Image:Slide1Linz7.jpg|thumb|40 [[GVCS]] technologies.]]
#CEB press - [[Full Product Release]] achieved.
#LifeTrac - on Prototype II
#Soil Pulverizer -

==See Also==

* [http://www.scrumhw.org/ Scrum for Hardware Product Development] ''Bringing Scrum to the Hardware Product Development Community''
* [http://maccherone.com/larry/2010/02/23/top-10-questions-when-using-agile-on-hardware-projects/ Top 10 questions when using Agile on hardware projects]

[[Category:Project Management]]

Scrum

2012-03-05T08:58:11Z

Mia Van Meter: /* OSE GVCS Scrum */

Definition: '''[[wikipedia:Scrum (development)|Scrum]]''' is an iterative and incremental methodology for software projects and product- or application-development. It is also one of the variants of [[wikipedia:agile software development|agile software development]] methodologies.

==Why would a development team use Scrum?==

As demonstrated by high-powered software teams around the world, the Scrum process can increase a development team's efficiency dramatically. In recent years, some Scrum coaches (Scrum Masters) can consistently get development teams to be six times more efficient, and it is becoming almost unremarkable for a Scrum Master to kick a team into a productive state 15 times more productive than in their pre-Scrum days.

Scrum is essentially a double handful of rules for how a team should work together, and how they should be managed. Underneath those rules is a profound understanding of human nature. What motivates us? That is the essential question which Scrum answers. Scrum rules are designed to instill ownership, motivation, and creative problem-solving in team members. The dramatic results of a well-functioning Scrum team come from the synchronistic multiplying effect of a group of developers working “in the flow.” [http://en.wikipedia.org/wiki/Jeff_Sutherland/ Jeff Sutherland], one of the creators of Scrum, refers to these as “activated” teams.

Following [http://en.wikipedia.org/wiki/Lean_software_development/ Lean] development principles, the rules of Scrum are stripped down to the essentials. One of the implications of this is that teams must adopt all the Scrum rules in order to get Scrum results. Jeff Sutherland's favorite lecture topic seems to be “Scrumbutt.” This occurs when teams say, “Yes, we're doing Scrum, but...” and explain an aspect of Scrum they decided not to implement. According to Sutherland, you cannot get dramatic results unless you are pretty much a Scrum purist. That said, Scrum can “wrap around” other software development process technologies like, for example, XP or Lean. It's not essential to understand those technologies fully, for our purposes, but they are mentioned in the discussion on this page.

The most relevant question for a project like OSE is – is Scrum applicable outside the software development world? This is the answer that Joe Justice and the WikiSpeed team answer with a resounding “Yes!” In the 10-minute TEDX talk below, he explains briefly how the WikiSpeed Team, a collection of 44 volunteers in 4 countries, in three months used Scrum and associated processes to design and build a road-certifiable 4-person commuter car that can get over 100 miles per gallon in standard EPA road tests. The relevance of this to OSE is obvious – a distributed team of volunteers co-developing revolutionary hardware, sound familiar? It's well worth your while to spend a few hours absorbing the information on Scrum that this page points to, and to help explore its relevance for OSE in general, and the GVCS in particular.

In this video, Joe Justice, of WikiSpeed, explains the process his all-volunteer design team used to exceed expectations in their fuel-efficient car design.

<html><iframe width="300" height="182" src="http://www.youtube.com/watch?v=x8jdx-lf2Dw" frameborder="0" allowfullscreen></iframe></html>

.
.

.
.

==What is Scrum?==

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/watch?v=Q5k7a9YEoUI" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
The video above is a great first introduction to Scrum! It's fast paced, and the graphics easily convey the important information.

Of course, like any single Scrum coach, this one has his own take on Scrum, and in some instances it's likely that OSE Scrum will be different.

To review his core concepts:

Roles: Product Owner, Scrum Master, Team Members (developers, testers, customers)

Release Planning:
*Product Backlog– Estimate for each feature wanted in product.
*Release Backlog
*plan 4-12 Sprints – a substantive back log to a ship-ready state
*Sprint Backlog

Burndown Chart – day by day measure of the amount of work left in a Release, or Sprint

Bugs – have a separate Defect Backlog. Resolve bugs within the Sprint.

Daily Scrum – short, standing, identify bugs.

So that video is a great introduction to Scrum, but how would we actually get started?

The Scrum process starts with the Product Owner. They are responsible for creating the Product Backlog, creating the Development Team, and for providing the Team with the tools necessary for them to work. The Scrum Master helps the Product Owner with these tasks.

===Sprint ZERO===

To get ready for the first development Sprint, the Product Owner and the Scrum Master need to meet together, and with the Team, and do some initial preparation. The amount of time spent on Sprint Zero should be limited, and agreed upon in advance. Unfinished preparation can be added to the Product Backlog when Sprint Zero is finished. Additionally, the task of adding to the Product Backlog, and refining features that are down the road a bit, will be ongoing tasks for the Product Owner.

The most important outcome of Sprint Zero is to create understanding about the value of the work. Given that OSE might choose to have a team (Scrum) of Product Owners, it could make implementation more clear if the business values we are creating are explicitly ranked. Usually the process of identifying and clarifying the business value is held more distantly from the Team. In the case of OSE, it seems likely that a group of people will be determining the relative priorities of our business values, and the relative rankings of the features that we're planning on creating.

We've been talking about ranking the features that make up the Product Backlog. In Scrum, these features are called Stories. There is an art to defining a Scrum Story, as you might imagine. Stories often take this form:

As _[User]_____, I want _[feature]_______, so that __[value]______.

An example:

* As a fabricator making a CNC Torch Table, I want complete and accurate CAD drawings, so that my efforts will result in a well-functioning machine.

Because the User is included in defining the feature, these are known as User Stories. The following video explains a good way to evaluate and improve User Stories, which are the list of features that make up the Product Backlog.

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=L_NyCczp0Fk&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.

To review the key ideas of the video:

'''Independent''' – dependencies among or between Stories need to be identified, eliminated, or tracked. An example of dependency: the training video for making a machine cannot be made until the machine is designed.
'''Negotiable''' – the Product Owner and the Team co-create the value and attributes of features (Stories)
'''Valuable''' – all Stories are connected directly to business value.
'''Estimable''' – the Team estimates the size of the Stories relative to each other.
'''Small''' – an important concept is raised here. Stories that are coming up in priority in the first or second Release should be small enough to be finished in one Sprint. Stories that are being implemented later can be large (Epics – more on this below).
'''Testable''' – knowing how we will know the Story is done, also called knowing the Definition of Done.

This review of the qualities of a good User Story gives some idea of the work to be done during Sprint Zero, while the User Stories are created, combined in one list, and then prioritized to make up the Product Backlog.

During Sprint Zero, the Product Owner will create a list of Epics. Epics are very large Stories. An example:
* As OSE, I want complete training materials in English for the 50 tools in GVCS on DVD, so that anyone with moderate experience in fabrication, and with access to the necessary tools and materials, can fabricate any of the 50 tools.

The list of Epics doesn't have to be exhaustive, but it should be thoroughly discussed and described, using the criteria for Stories developed in the video above.

Here are some further questions to be taken up during Sprint Zero:
* Do we have the right people with the right skills? Is there a need for consultants, etc.?

* Given the Epics, the values, and the definitions of done, what sort of work place, tools and technology set up are indicated?

* What is the general approach we are taking? What will be the length of our Sprints? What is the Road Map -- the key release points? How many teams will there be? If there are multiple teams, how will the Scrum Masters and the Product Owners from the multiple teams work together?

At the end of Sprint Zero, the Product Backlog must contain enough prioritized Stories to fill at least the first Release. Ideally, there would be enough Stories for two or three releases, so that the broad outlines of the technology and personnel needed can be understood.

Here's a possible outline for Sprint Zero:
Describe final product
Create a team(s) workspace(s)
Determine the length of sprints
Identify business value (the criteria to measure the value of work as it's done)
Create epics. Prioritize epics (consider relative business value)
For the highest priority epic, turn the epic into stories
Prioritize the stories (consider relative business value)
For each story, create a definition of done

===Definition of Done===

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=9FnZsaRujpw&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
NOTE -- this video is LOUD!

Review of the main concepts of the video:

This video is from Agile; Scrum is one form of Agile. So in this video you don't see mention of a Scrum Master. Instead they talk about a Team Lead. However, the content on Definition of Done is relevant for OSE.

In this video he is discussing creating the Definition of Done at the Team level. The Product Owner needs to first supply the Team with an initial Definition of Done feature by feature. The Product Owner's Definition of Done revolves around the What (and explains the Why). The Team's Definition of Done defines the How.

In the video, he refers to "blockers," which are usually referred to in Scrum as Impediments. More on that later...

One value of this video is that it stresses how all members of a multi-functional Team get involved in creating the Definition of Done. It is crucial that this Definition is agreed to by everyone on the Team. When the Team commits to the work included in a Release, and in each Sprint, they are doing so based on the agreed on Definition of Done for each Story.

There is quite a bit of excess jargon in this video, but have patience, and relate it to GVCS. For example, we not only need to have the machine design "done," but also CAD drawings, an instructional video, and many other instructional components. Unifying the release and "done-ness" of all of these is what seems like the best, and most radical!, contribution Scrum can make to GVCS. These underlying points of “What is Done?” are crucial for us to understand the work that is needed in Sprint Zero.

==OSE [[GVCS]] Scrum==

Steps to take to convert OSE to Scrum:

1) Identify a Product Owner and Scrum Master
2) The Scrum Master helps the Product Owner identify the Stories and business values.
3) Decide whether to use collaborative online Scrum software (especially for the Product Backlog)
3) Decide who will participate in Sprint Zero, how long it will be, and the format.

First, we list the projects, in order of priority. See GVCS graphic on the right. Changes are: remove pyrolysis oil and [[Babington burner]] with biomass [[Pelletizer]] for fueling modern [[Steam Engine]]s. The burner is already present in the form of the [[:File:Gasifiericon.jpg|Gasifier Icon]]
[[Image:Slide1Linz7.jpg|thumb|40 [[GVCS]] technologies.]]
#CEB press - [[Full Product Release]] achieved.
#LifeTrac - on Prototype II
#Soil Pulverizer -

==See Also==

* [http://www.scrumhw.org/ Scrum for Hardware Product Development] ''Bringing Scrum to the Hardware Product Development Community''
* [http://maccherone.com/larry/2010/02/23/top-10-questions-when-using-agile-on-hardware-projects/ Top 10 questions when using Agile on hardware projects]

[[Category:Project Management]]

Scrum

2012-03-05T08:47:23Z

Mia Van Meter: /* Why would a development team use Scrum? */

Definition: '''[[wikipedia:Scrum (development)|Scrum]]''' is an iterative and incremental methodology for software projects and product- or application-development. It is also one of the variants of [[wikipedia:agile software development|agile software development]] methodologies.

==Why would a development team use Scrum?==

As demonstrated by high-powered software teams around the world, the Scrum process can increase a development team's efficiency dramatically. In recent years, some Scrum coaches (Scrum Masters) can consistently get development teams to be six times more efficient, and it is becoming almost unremarkable for a Scrum Master to kick a team into a productive state 15 times more productive than in their pre-Scrum days.

Scrum is essentially a double handful of rules for how a team should work together, and how they should be managed. Underneath those rules is a profound understanding of human nature. What motivates us? That is the essential question which Scrum answers. Scrum rules are designed to instill ownership, motivation, and creative problem-solving in team members. The dramatic results of a well-functioning Scrum team come from the synchronistic multiplying effect of a group of developers working “in the flow.” [http://en.wikipedia.org/wiki/Jeff_Sutherland/ Jeff Sutherland], one of the creators of Scrum, refers to these as “activated” teams.

Following [http://en.wikipedia.org/wiki/Lean_software_development/ Lean] development principles, the rules of Scrum are stripped down to the essentials. One of the implications of this is that teams must adopt all the Scrum rules in order to get Scrum results. Jeff Sutherland's favorite lecture topic seems to be “Scrumbutt.” This occurs when teams say, “Yes, we're doing Scrum, but...” and explain an aspect of Scrum they decided not to implement. According to Sutherland, you cannot get dramatic results unless you are pretty much a Scrum purist. That said, Scrum can “wrap around” other software development process technologies like, for example, XP or Lean. It's not essential to understand those technologies fully, for our purposes, but they are mentioned in the discussion on this page.

The most relevant question for a project like OSE is – is Scrum applicable outside the software development world? This is the answer that Joe Justice and the WikiSpeed team answer with a resounding “Yes!” In the 10-minute TEDX talk below, he explains briefly how the WikiSpeed Team, a collection of 44 volunteers in 4 countries, in three months used Scrum and associated processes to design and build a road-certifiable 4-person commuter car that can get over 100 miles per gallon in standard EPA road tests. The relevance of this to OSE is obvious – a distributed team of volunteers co-developing revolutionary hardware, sound familiar? It's well worth your while to spend a few hours absorbing the information on Scrum that this page points to, and to help explore its relevance for OSE in general, and the GVCS in particular.

In this video, Joe Justice, of WikiSpeed, explains the process his all-volunteer design team used to exceed expectations in their fuel-efficient car design.

<html><iframe width="300" height="182" src="http://www.youtube.com/watch?v=x8jdx-lf2Dw" frameborder="0" allowfullscreen></iframe></html>

.
.

.
.

==What is Scrum?==

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/watch?v=Q5k7a9YEoUI" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
The video above is a great first introduction to Scrum! It's fast paced, and the graphics easily convey the important information.

Of course, like any single Scrum coach, this one has his own take on Scrum, and in some instances it's likely that OSE Scrum will be different.

To review his core concepts:

Roles: Product Owner, Scrum Master, Team Members (developers, testers, customers)

Release Planning:
*Product Backlog– Estimate for each feature wanted in product.
*Release Backlog
*plan 4-12 Sprints – a substantive back log to a ship-ready state
*Sprint Backlog

Burndown Chart – day by day measure of the amount of work left in a Release, or Sprint

Bugs – have a separate Defect Backlog. Resolve bugs within the Sprint.

Daily Scrum – short, standing, identify bugs.

So that video is a great introduction to Scrum, but how would we actually get started?

The Scrum process starts with the Product Owner. They are responsible for creating the Product Backlog, creating the Development Team, and for providing the Team with the tools necessary for them to work. The Scrum Master helps the Product Owner with these tasks.

===Sprint ZERO===

To get ready for the first development Sprint, the Product Owner and the Scrum Master need to meet together, and with the Team, and do some initial preparation. The amount of time spent on Sprint Zero should be limited, and agreed upon in advance. Unfinished preparation can be added to the Product Backlog when Sprint Zero is finished. Additionally, the task of adding to the Product Backlog, and refining features that are down the road a bit, will be ongoing tasks for the Product Owner.

The most important outcome of Sprint Zero is to create understanding about the value of the work. Given that OSE might choose to have a team (Scrum) of Product Owners, it could make implementation more clear if the business values we are creating are explicitly ranked. Usually the process of identifying and clarifying the business value is held more distantly from the Team. In the case of OSE, it seems likely that a group of people will be determining the relative priorities of our business values, and the relative rankings of the features that we're planning on creating.

We've been talking about ranking the features that make up the Product Backlog. In Scrum, these features are called Stories. There is an art to defining a Scrum Story, as you might imagine. Stories often take this form:

As _[User]_____, I want _[feature]_______, so that __[value]______.

An example:

* As a fabricator making a CNC Torch Table, I want complete and accurate CAD drawings, so that my efforts will result in a well-functioning machine.

Because the User is included in defining the feature, these are known as User Stories. The following video explains a good way to evaluate and improve User Stories, which are the list of features that make up the Product Backlog.

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=L_NyCczp0Fk&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.

To review the key ideas of the video:

'''Independent''' – dependencies among or between Stories need to be identified, eliminated, or tracked. An example of dependency: the training video for making a machine cannot be made until the machine is designed.
'''Negotiable''' – the Product Owner and the Team co-create the value and attributes of features (Stories)
'''Valuable''' – all Stories are connected directly to business value.
'''Estimable''' – the Team estimates the size of the Stories relative to each other.
'''Small''' – an important concept is raised here. Stories that are coming up in priority in the first or second Release should be small enough to be finished in one Sprint. Stories that are being implemented later can be large (Epics – more on this below).
'''Testable''' – knowing how we will know the Story is done, also called knowing the Definition of Done.

This review of the qualities of a good User Story gives some idea of the work to be done during Sprint Zero, while the User Stories are created, combined in one list, and then prioritized to make up the Product Backlog.

During Sprint Zero, the Product Owner will create a list of Epics. Epics are very large Stories. An example:
* As OSE, I want complete training materials in English for the 50 tools in GVCS on DVD, so that anyone with moderate experience in fabrication, and with access to the necessary tools and materials, can fabricate any of the 50 tools.

The list of Epics doesn't have to be exhaustive, but it should be thoroughly discussed and described, using the criteria for Stories developed in the video above.

Here are some further questions to be taken up during Sprint Zero:
* Do we have the right people with the right skills? Is there a need for consultants, etc.?

* Given the Epics, the values, and the definitions of done, what sort of work place, tools and technology set up are indicated?

* What is the general approach we are taking? What will be the length of our Sprints? What is the Road Map -- the key release points? How many teams will there be? If there are multiple teams, how will the Scrum Masters and the Product Owners from the multiple teams work together?

At the end of Sprint Zero, the Product Backlog must contain enough prioritized Stories to fill at least the first Release. Ideally, there would be enough Stories for two or three releases, so that the broad outlines of the technology and personnel needed can be understood.

Here's a possible outline for Sprint Zero:
Describe final product
Create a team(s) workspace(s)
Determine the length of sprints
Identify business value (the criteria to measure the value of work as it's done)
Create epics. Prioritize epics (consider relative business value)
For the highest priority epic, turn the epic into stories
Prioritize the stories (consider relative business value)
For each story, create a definition of done

===Definition of Done===

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=9FnZsaRujpw&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
NOTE -- this video is LOUD!

Review of the main concepts of the video:

This video is from Agile; Scrum is one form of Agile. So in this video you don't see mention of a Scrum Master. Instead they talk about a Team Lead. However, the content on Definition of Done is relevant for OSE.

In this video he is discussing creating the Definition of Done at the Team level. The Product Owner needs to first supply the Team with an initial Definition of Done feature by feature. The Product Owner's Definition of Done revolves around the What (and explains the Why). The Team's Definition of Done defines the How.

In the video, he refers to "blockers," which are usually referred to in Scrum as Impediments. More on that later...

One value of this video is that it stresses how all members of a multi-functional Team get involved in creating the Definition of Done. It is crucial that this Definition is agreed to by everyone on the Team. When the Team commits to the work included in a Release, and in each Sprint, they are doing so based on the agreed on Definition of Done for each Story.

There is quite a bit of excess jargon in this video, but have patience, and relate it to GVCS. For example, we not only need to have the machine design "done," but also CAD drawings, an instructional video, and many other instructional components. Unifying the release and "done-ness" of all of these is what seems like the best, and most radical!, contribution Scrum can make to GVCS. These underlying points of “What is Done?” are crucial for us to understand the work that is needed in Sprint Zero.

==OSE [[GVCS]] Scrum==

First, we list the projects, in order of priority. See GVCS graphic on the right. Changes are: remove pyrolysis oil and [[Babington burner]] with biomass [[Pelletizer]] for fueling modern [[Steam Engine]]s. The burner is already present in the form of the [[:File:Gasifiericon.jpg|Gasifier Icon]]
[[Image:Slide1Linz7.jpg|thumb|40 [[GVCS]] technologies.]]
#CEB press - [[Full Product Release]] achieved.
#LifeTrac - on Prototype II
#Soil Pulverizer -

==See Also==

* [http://www.scrumhw.org/ Scrum for Hardware Product Development] ''Bringing Scrum to the Hardware Product Development Community''
* [http://maccherone.com/larry/2010/02/23/top-10-questions-when-using-agile-on-hardware-projects/ Top 10 questions when using Agile on hardware projects]

[[Category:Project Management]]

Scrum

2012-03-05T03:17:48Z

Mia Van Meter: /* What is Scrum? */

Definition: '''[[wikipedia:Scrum (development)|Scrum]]''' is an iterative and incremental methodology for software projects and product- or application-development. It is also one of the variants of [[wikipedia:agile software development|agile software development]] methodologies.

==Why would a development team use Scrum?==

As demonstrated by high-powered software teams around the world, the Scrum process can increase a development team's efficiency dramatically. In recent years, some Scrum coaches (Scrum Masters) can consistently get development teams to be six times more efficient, and it is becoming almost unremarkable for a Scrum Master to kick a team into a productive state 15 times more productive than in their pre-Scrum days.

The adoption of Scrum by Western development teams is part of a grand mimicking of Japanese manufacturing techniques, which has been going on, with patterns of waxing and waning, for many decades. Software development has become a big enough industry that its leading edge is penetrating many other industries. Its leading edge is the family of development management processes called Agile, one of which, the most popular, is Scrum.

Scrum is essentially a double handful of rules for how a team should work together, and how they should be managed. Underneath those rules is a profound understanding of human nature. What motivates us? That is the essential question which Scrum answers. Scrum rules are designed to instill ownership, motivation, and creative problem-solving in team members. The dramatic results of a well-functioning Scrum team come from the synchronistic multiplying effect of a group of developers working “in the flow.” [http://en.wikipedia.org/wiki/Jeff_Sutherland/ Jeff Sutherland], one of the creators of Scrum, refers to these as “activated” teams.

Following [http://en.wikipedia.org/wiki/Lean_software_development/ Lean] development principles, the rules of Scrum are stripped down to the essentials. One of the implications of this is that teams must adopt all the Scrum rules in order to get Scrum results. Jeff Sutherland's favorite lecture topic seems to be “Scrumbutt.” This occurs when teams say, “Yes, we're doing Scrum, but...” and explain an aspect of Scrum they decided not to implement. According to Sutherland, you cannot get dramatic results unless you are pretty much a Scrum purist. That said, Scrum can “wrap around” other software development process technologies like, for example, XP or Lean. It's not essential to understand those technologies fully, for our purposes, but they are mentioned in the discussion on this page.

The most relevant question for a project like OSE is – is Scrum applicable outside the software development world? This is the answer that Joe Justice and the WikiSpeed team answer with a resounding “Yes!” In the 10-minute TEDX talk below, he explains briefly how the WikiSpeed Team, a collection of 44 volunteers in 4 countries, in three months used Scrum and associated processes to design and build a road-certifiable 4-person commuter car that can get over 100 miles per gallon in standard EPA road tests. The relevance of this to OSE is obvious – a distributed team of volunteers co-developing revolutionary hardware, sound familiar? It's well worth your while to spend a few hours absorbing the information on Scrum that this page points to, and to help explore its relevance for OSE in general, and the GVCS in particular.

In this video, Joe Justice, of WikiSpeed, explains the process his all-volunteer design team used to exceed expectations in their fuel-efficient car design.

<html><iframe width="300" height="182" src="http://www.youtube.com/watch?v=x8jdx-lf2Dw" frameborder="0" allowfullscreen></iframe></html>

.
.

.
.

==What is Scrum?==

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/watch?v=Q5k7a9YEoUI" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
The video above is a great first introduction to Scrum! It's fast paced, and the graphics easily convey the important information.

Of course, like any single Scrum coach, this one has his own take on Scrum, and in some instances it's likely that OSE Scrum will be different.

To review his core concepts:

Roles: Product Owner, Scrum Master, Team Members (developers, testers, customers)

Release Planning:
*Product Backlog– Estimate for each feature wanted in product.
*Release Backlog
*plan 4-12 Sprints – a substantive back log to a ship-ready state
*Sprint Backlog

Burndown Chart – day by day measure of the amount of work left in a Release, or Sprint

Bugs – have a separate Defect Backlog. Resolve bugs within the Sprint.

Daily Scrum – short, standing, identify bugs.

So that video is a great introduction to Scrum, but how would we actually get started?

The Scrum process starts with the Product Owner. They are responsible for creating the Product Backlog, creating the Development Team, and for providing the Team with the tools necessary for them to work. The Scrum Master helps the Product Owner with these tasks.

===Sprint ZERO===

To get ready for the first development Sprint, the Product Owner and the Scrum Master need to meet together, and with the Team, and do some initial preparation. The amount of time spent on Sprint Zero should be limited, and agreed upon in advance. Unfinished preparation can be added to the Product Backlog when Sprint Zero is finished. Additionally, the task of adding to the Product Backlog, and refining features that are down the road a bit, will be ongoing tasks for the Product Owner.

The most important outcome of Sprint Zero is to create understanding about the value of the work. Given that OSE might choose to have a team (Scrum) of Product Owners, it could make implementation more clear if the business values we are creating are explicitly ranked. Usually the process of identifying and clarifying the business value is held more distantly from the Team. In the case of OSE, it seems likely that a group of people will be determining the relative priorities of our business values, and the relative rankings of the features that we're planning on creating.

We've been talking about ranking the features that make up the Product Backlog. In Scrum, these features are called Stories. There is an art to defining a Scrum Story, as you might imagine. Stories often take this form:

As _[User]_____, I want _[feature]_______, so that __[value]______.

An example:

* As a fabricator making a CNC Torch Table, I want complete and accurate CAD drawings, so that my efforts will result in a well-functioning machine.

Because the User is included in defining the feature, these are known as User Stories. The following video explains a good way to evaluate and improve User Stories, which are the list of features that make up the Product Backlog.

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=L_NyCczp0Fk&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.

To review the key ideas of the video:

'''Independent''' – dependencies among or between Stories need to be identified, eliminated, or tracked. An example of dependency: the training video for making a machine cannot be made until the machine is designed.
'''Negotiable''' – the Product Owner and the Team co-create the value and attributes of features (Stories)
'''Valuable''' – all Stories are connected directly to business value.
'''Estimable''' – the Team estimates the size of the Stories relative to each other.
'''Small''' – an important concept is raised here. Stories that are coming up in priority in the first or second Release should be small enough to be finished in one Sprint. Stories that are being implemented later can be large (Epics – more on this below).
'''Testable''' – knowing how we will know the Story is done, also called knowing the Definition of Done.

This review of the qualities of a good User Story gives some idea of the work to be done during Sprint Zero, while the User Stories are created, combined in one list, and then prioritized to make up the Product Backlog.

During Sprint Zero, the Product Owner will create a list of Epics. Epics are very large Stories. An example:
* As OSE, I want complete training materials in English for the 50 tools in GVCS on DVD, so that anyone with moderate experience in fabrication, and with access to the necessary tools and materials, can fabricate any of the 50 tools.

The list of Epics doesn't have to be exhaustive, but it should be thoroughly discussed and described, using the criteria for Stories developed in the video above.

Here are some further questions to be taken up during Sprint Zero:
* Do we have the right people with the right skills? Is there a need for consultants, etc.?

* Given the Epics, the values, and the definitions of done, what sort of work place, tools and technology set up are indicated?

* What is the general approach we are taking? What will be the length of our Sprints? What is the Road Map -- the key release points? How many teams will there be? If there are multiple teams, how will the Scrum Masters and the Product Owners from the multiple teams work together?

At the end of Sprint Zero, the Product Backlog must contain enough prioritized Stories to fill at least the first Release. Ideally, there would be enough Stories for two or three releases, so that the broad outlines of the technology and personnel needed can be understood.

Here's a possible outline for Sprint Zero:
Describe final product
Create a team(s) workspace(s)
Determine the length of sprints
Identify business value (the criteria to measure the value of work as it's done)
Create epics. Prioritize epics (consider relative business value)
For the highest priority epic, turn the epic into stories
Prioritize the stories (consider relative business value)
For each story, create a definition of done

===Definition of Done===

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=9FnZsaRujpw&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
NOTE -- this video is LOUD!

Review of the main concepts of the video:

This video is from Agile; Scrum is one form of Agile. So in this video you don't see mention of a Scrum Master. Instead they talk about a Team Lead. However, the content on Definition of Done is relevant for OSE.

In this video he is discussing creating the Definition of Done at the Team level. The Product Owner needs to first supply the Team with an initial Definition of Done feature by feature. The Product Owner's Definition of Done revolves around the What (and explains the Why). The Team's Definition of Done defines the How.

In the video, he refers to "blockers," which are usually referred to in Scrum as Impediments. More on that later...

One value of this video is that it stresses how all members of a multi-functional Team get involved in creating the Definition of Done. It is crucial that this Definition is agreed to by everyone on the Team. When the Team commits to the work included in a Release, and in each Sprint, they are doing so based on the agreed on Definition of Done for each Story.

There is quite a bit of excess jargon in this video, but have patience, and relate it to GVCS. For example, we not only need to have the machine design "done," but also CAD drawings, an instructional video, and many other instructional components. Unifying the release and "done-ness" of all of these is what seems like the best, and most radical!, contribution Scrum can make to GVCS. These underlying points of “What is Done?” are crucial for us to understand the work that is needed in Sprint Zero.

==OSE [[GVCS]] Scrum==

First, we list the projects, in order of priority. See GVCS graphic on the right. Changes are: remove pyrolysis oil and [[Babington burner]] with biomass [[Pelletizer]] for fueling modern [[Steam Engine]]s. The burner is already present in the form of the [[:File:Gasifiericon.jpg|Gasifier Icon]]
[[Image:Slide1Linz7.jpg|thumb|40 [[GVCS]] technologies.]]
#CEB press - [[Full Product Release]] achieved.
#LifeTrac - on Prototype II
#Soil Pulverizer -

==See Also==

* [http://www.scrumhw.org/ Scrum for Hardware Product Development] ''Bringing Scrum to the Hardware Product Development Community''
* [http://maccherone.com/larry/2010/02/23/top-10-questions-when-using-agile-on-hardware-projects/ Top 10 questions when using Agile on hardware projects]

[[Category:Project Management]]

Scrum

2012-03-05T02:54:59Z

Mia Van Meter: /* Definition of Done */

Definition: '''[[wikipedia:Scrum (development)|Scrum]]''' is an iterative and incremental methodology for software projects and product- or application-development. It is also one of the variants of [[wikipedia:agile software development|agile software development]] methodologies.

==Why would a development team use Scrum?==

As demonstrated by high-powered software teams around the world, the Scrum process can increase a development team's efficiency dramatically. In recent years, some Scrum coaches (Scrum Masters) can consistently get development teams to be six times more efficient, and it is becoming almost unremarkable for a Scrum Master to kick a team into a productive state 15 times more productive than in their pre-Scrum days.

The adoption of Scrum by Western development teams is part of a grand mimicking of Japanese manufacturing techniques, which has been going on, with patterns of waxing and waning, for many decades. Software development has become a big enough industry that its leading edge is penetrating many other industries. Its leading edge is the family of development management processes called Agile, one of which, the most popular, is Scrum.

Scrum is essentially a double handful of rules for how a team should work together, and how they should be managed. Underneath those rules is a profound understanding of human nature. What motivates us? That is the essential question which Scrum answers. Scrum rules are designed to instill ownership, motivation, and creative problem-solving in team members. The dramatic results of a well-functioning Scrum team come from the synchronistic multiplying effect of a group of developers working “in the flow.” [http://en.wikipedia.org/wiki/Jeff_Sutherland/ Jeff Sutherland], one of the creators of Scrum, refers to these as “activated” teams.

Following [http://en.wikipedia.org/wiki/Lean_software_development/ Lean] development principles, the rules of Scrum are stripped down to the essentials. One of the implications of this is that teams must adopt all the Scrum rules in order to get Scrum results. Jeff Sutherland's favorite lecture topic seems to be “Scrumbutt.” This occurs when teams say, “Yes, we're doing Scrum, but...” and explain an aspect of Scrum they decided not to implement. According to Sutherland, you cannot get dramatic results unless you are pretty much a Scrum purist. That said, Scrum can “wrap around” other software development process technologies like, for example, XP or Lean. It's not essential to understand those technologies fully, for our purposes, but they are mentioned in the discussion on this page.

The most relevant question for a project like OSE is – is Scrum applicable outside the software development world? This is the answer that Joe Justice and the WikiSpeed team answer with a resounding “Yes!” In the 10-minute TEDX talk below, he explains briefly how the WikiSpeed Team, a collection of 44 volunteers in 4 countries, in three months used Scrum and associated processes to design and build a road-certifiable 4-person commuter car that can get over 100 miles per gallon in standard EPA road tests. The relevance of this to OSE is obvious – a distributed team of volunteers co-developing revolutionary hardware, sound familiar? It's well worth your while to spend a few hours absorbing the information on Scrum that this page points to, and to help explore its relevance for OSE in general, and the GVCS in particular.

In this video, Joe Justice, of WikiSpeed, explains the process his all-volunteer design team used to exceed expectations in their fuel-efficient car design.

<html><iframe width="300" height="182" src="http://www.youtube.com/watch?v=x8jdx-lf2Dw" frameborder="0" allowfullscreen></iframe></html>

.
.

.
.

==What is Scrum?==

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/watch?v=Q5k7a9YEoUI" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
The video above is a great first introduction to Scrum! It's fast paced, and the graphics easily convey the important information.

Of course, like any single Scrum coach, this one has his own take on Scrum, and in some instances it's likely that OSE Scrum will be different.

To review his core concepts:

Roles: Product Owner, Scrum Master, Team Members (developers, testers, customers)

Release Planning:
Product Backlog– Estimate for each feature wanted in product.
Release Backlog
plan 4-12 Sprints – a substantive back log to a ship-ready state
Sprint Backlog

Burndown Chart – day by day measure of the amount of work left in a Release, or Sprint

Bugs – have a separate Defect Backlog. Resolve bugs within the Sprint.

Daily Scrum – short, standing, identify bugs.

So that video is a great introduction to Scrum, but how would we actually get started?

The Scrum process starts with the Product Owner. They are responsible for creating the Product Backlog, creating the Development Team, and for providing the Team with the tools necessary for them to work. The Scrum Master helps the Product Owner with these tasks.

===Sprint ZERO===

To get ready for the first development Sprint, the Product Owner and the Scrum Master need to meet together, and with the Team, and do some initial preparation. The amount of time spent on Sprint Zero should be limited, and agreed upon in advance. Unfinished preparation can be added to the Product Backlog when Sprint Zero is finished. Additionally, the task of adding to the Product Backlog, and refining features that are down the road a bit, will be ongoing tasks for the Product Owner.

The most important outcome of Sprint Zero is to create understanding about the value of the work. Given that OSE might choose to have a team (Scrum) of Product Owners, it could make implementation more clear if the business values we are creating are explicitly ranked. Usually the process of identifying and clarifying the business value is held more distantly from the Team. In the case of OSE, it seems likely that a group of people will be determining the relative priorities of our business values, and the relative rankings of the features that we're planning on creating.

We've been talking about ranking the features that make up the Product Backlog. In Scrum, these features are called Stories. There is an art to defining a Scrum Story, as you might imagine. Stories often take this form:

As _[User]_____, I want _[feature]_______, so that __[value]______.

An example:

* As a fabricator making a CNC Torch Table, I want complete and accurate CAD drawings, so that my efforts will result in a well-functioning machine.

Because the User is included in defining the feature, these are known as User Stories. The following video explains a good way to evaluate and improve User Stories, which are the list of features that make up the Product Backlog.

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=L_NyCczp0Fk&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.

To review the key ideas of the video:

'''Independent''' – dependencies among or between Stories need to be identified, eliminated, or tracked. An example of dependency: the training video for making a machine cannot be made until the machine is designed.
'''Negotiable''' – the Product Owner and the Team co-create the value and attributes of features (Stories)
'''Valuable''' – all Stories are connected directly to business value.
'''Estimable''' – the Team estimates the size of the Stories relative to each other.
'''Small''' – an important concept is raised here. Stories that are coming up in priority in the first or second Release should be small enough to be finished in one Sprint. Stories that are being implemented later can be large (Epics – more on this below).
'''Testable''' – knowing how we will know the Story is done, also called knowing the Definition of Done.

This review of the qualities of a good User Story gives some idea of the work to be done during Sprint Zero, while the User Stories are created, combined in one list, and then prioritized to make up the Product Backlog.

During Sprint Zero, the Product Owner will create a list of Epics. Epics are very large Stories. An example:
* As OSE, I want complete training materials in English for the 50 tools in GVCS on DVD, so that anyone with moderate experience in fabrication, and with access to the necessary tools and materials, can fabricate any of the 50 tools.

The list of Epics doesn't have to be exhaustive, but it should be thoroughly discussed and described, using the criteria for Stories developed in the video above.

Here are some further questions to be taken up during Sprint Zero:
* Do we have the right people with the right skills? Is there a need for consultants, etc.?

* Given the Epics, the values, and the definitions of done, what sort of work place, tools and technology set up are indicated?

* What is the general approach we are taking? What will be the length of our Sprints? What is the Road Map -- the key release points? How many teams will there be? If there are multiple teams, how will the Scrum Masters and the Product Owners from the multiple teams work together?

At the end of Sprint Zero, the Product Backlog must contain enough prioritized Stories to fill at least the first Release. Ideally, there would be enough Stories for two or three releases, so that the broad outlines of the technology and personnel needed can be understood.

Here's a possible outline for Sprint Zero:
Describe final product
Create a team(s) workspace(s)
Determine the length of sprints
Identify business value (the criteria to measure the value of work as it's done)
Create epics. Prioritize epics (consider relative business value)
For the highest priority epic, turn the epic into stories
Prioritize the stories (consider relative business value)
For each story, create a definition of done

===Definition of Done===

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=9FnZsaRujpw&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
NOTE -- this video is LOUD!

Review of the main concepts of the video:

This video is from Agile; Scrum is one form of Agile. So in this video you don't see mention of a Scrum Master. Instead they talk about a Team Lead. However, the content on Definition of Done is relevant for OSE.

In this video he is discussing creating the Definition of Done at the Team level. The Product Owner needs to first supply the Team with an initial Definition of Done feature by feature. The Product Owner's Definition of Done revolves around the What (and explains the Why). The Team's Definition of Done defines the How.

In the video, he refers to "blockers," which are usually referred to in Scrum as Impediments. More on that later...

One value of this video is that it stresses how all members of a multi-functional Team get involved in creating the Definition of Done. It is crucial that this Definition is agreed to by everyone on the Team. When the Team commits to the work included in a Release, and in each Sprint, they are doing so based on the agreed on Definition of Done for each Story.

There is quite a bit of excess jargon in this video, but have patience, and relate it to GVCS. For example, we not only need to have the machine design "done," but also CAD drawings, an instructional video, and many other instructional components. Unifying the release and "done-ness" of all of these is what seems like the best, and most radical!, contribution Scrum can make to GVCS. These underlying points of “What is Done?” are crucial for us to understand the work that is needed in Sprint Zero.

==OSE [[GVCS]] Scrum==

First, we list the projects, in order of priority. See GVCS graphic on the right. Changes are: remove pyrolysis oil and [[Babington burner]] with biomass [[Pelletizer]] for fueling modern [[Steam Engine]]s. The burner is already present in the form of the [[:File:Gasifiericon.jpg|Gasifier Icon]]
[[Image:Slide1Linz7.jpg|thumb|40 [[GVCS]] technologies.]]
#CEB press - [[Full Product Release]] achieved.
#LifeTrac - on Prototype II
#Soil Pulverizer -

==See Also==

* [http://www.scrumhw.org/ Scrum for Hardware Product Development] ''Bringing Scrum to the Hardware Product Development Community''
* [http://maccherone.com/larry/2010/02/23/top-10-questions-when-using-agile-on-hardware-projects/ Top 10 questions when using Agile on hardware projects]

[[Category:Project Management]]

Scrum

2012-03-05T02:53:45Z

Mia Van Meter: /* Definition of Done */

Definition: '''[[wikipedia:Scrum (development)|Scrum]]''' is an iterative and incremental methodology for software projects and product- or application-development. It is also one of the variants of [[wikipedia:agile software development|agile software development]] methodologies.

==Why would a development team use Scrum?==

As demonstrated by high-powered software teams around the world, the Scrum process can increase a development team's efficiency dramatically. In recent years, some Scrum coaches (Scrum Masters) can consistently get development teams to be six times more efficient, and it is becoming almost unremarkable for a Scrum Master to kick a team into a productive state 15 times more productive than in their pre-Scrum days.

The adoption of Scrum by Western development teams is part of a grand mimicking of Japanese manufacturing techniques, which has been going on, with patterns of waxing and waning, for many decades. Software development has become a big enough industry that its leading edge is penetrating many other industries. Its leading edge is the family of development management processes called Agile, one of which, the most popular, is Scrum.

Scrum is essentially a double handful of rules for how a team should work together, and how they should be managed. Underneath those rules is a profound understanding of human nature. What motivates us? That is the essential question which Scrum answers. Scrum rules are designed to instill ownership, motivation, and creative problem-solving in team members. The dramatic results of a well-functioning Scrum team come from the synchronistic multiplying effect of a group of developers working “in the flow.” [http://en.wikipedia.org/wiki/Jeff_Sutherland/ Jeff Sutherland], one of the creators of Scrum, refers to these as “activated” teams.

Following [http://en.wikipedia.org/wiki/Lean_software_development/ Lean] development principles, the rules of Scrum are stripped down to the essentials. One of the implications of this is that teams must adopt all the Scrum rules in order to get Scrum results. Jeff Sutherland's favorite lecture topic seems to be “Scrumbutt.” This occurs when teams say, “Yes, we're doing Scrum, but...” and explain an aspect of Scrum they decided not to implement. According to Sutherland, you cannot get dramatic results unless you are pretty much a Scrum purist. That said, Scrum can “wrap around” other software development process technologies like, for example, XP or Lean. It's not essential to understand those technologies fully, for our purposes, but they are mentioned in the discussion on this page.

The most relevant question for a project like OSE is – is Scrum applicable outside the software development world? This is the answer that Joe Justice and the WikiSpeed team answer with a resounding “Yes!” In the 10-minute TEDX talk below, he explains briefly how the WikiSpeed Team, a collection of 44 volunteers in 4 countries, in three months used Scrum and associated processes to design and build a road-certifiable 4-person commuter car that can get over 100 miles per gallon in standard EPA road tests. The relevance of this to OSE is obvious – a distributed team of volunteers co-developing revolutionary hardware, sound familiar? It's well worth your while to spend a few hours absorbing the information on Scrum that this page points to, and to help explore its relevance for OSE in general, and the GVCS in particular.

In this video, Joe Justice, of WikiSpeed, explains the process his all-volunteer design team used to exceed expectations in their fuel-efficient car design.

<html><iframe width="300" height="182" src="http://www.youtube.com/watch?v=x8jdx-lf2Dw" frameborder="0" allowfullscreen></iframe></html>

.
.

.
.

==What is Scrum?==

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/watch?v=Q5k7a9YEoUI" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
The video above is a great first introduction to Scrum! It's fast paced, and the graphics easily convey the important information.

Of course, like any single Scrum coach, this one has his own take on Scrum, and in some instances it's likely that OSE Scrum will be different.

To review his core concepts:

Roles: Product Owner, Scrum Master, Team Members (developers, testers, customers)

Release Planning:
Product Backlog– Estimate for each feature wanted in product.
Release Backlog
plan 4-12 Sprints – a substantive back log to a ship-ready state
Sprint Backlog

Burndown Chart – day by day measure of the amount of work left in a Release, or Sprint

Bugs – have a separate Defect Backlog. Resolve bugs within the Sprint.

Daily Scrum – short, standing, identify bugs.

So that video is a great introduction to Scrum, but how would we actually get started?

The Scrum process starts with the Product Owner. They are responsible for creating the Product Backlog, creating the Development Team, and for providing the Team with the tools necessary for them to work. The Scrum Master helps the Product Owner with these tasks.

===Sprint ZERO===

To get ready for the first development Sprint, the Product Owner and the Scrum Master need to meet together, and with the Team, and do some initial preparation. The amount of time spent on Sprint Zero should be limited, and agreed upon in advance. Unfinished preparation can be added to the Product Backlog when Sprint Zero is finished. Additionally, the task of adding to the Product Backlog, and refining features that are down the road a bit, will be ongoing tasks for the Product Owner.

The most important outcome of Sprint Zero is to create understanding about the value of the work. Given that OSE might choose to have a team (Scrum) of Product Owners, it could make implementation more clear if the business values we are creating are explicitly ranked. Usually the process of identifying and clarifying the business value is held more distantly from the Team. In the case of OSE, it seems likely that a group of people will be determining the relative priorities of our business values, and the relative rankings of the features that we're planning on creating.

We've been talking about ranking the features that make up the Product Backlog. In Scrum, these features are called Stories. There is an art to defining a Scrum Story, as you might imagine. Stories often take this form:

As _[User]_____, I want _[feature]_______, so that __[value]______.

An example:

* As a fabricator making a CNC Torch Table, I want complete and accurate CAD drawings, so that my efforts will result in a well-functioning machine.

Because the User is included in defining the feature, these are known as User Stories. The following video explains a good way to evaluate and improve User Stories, which are the list of features that make up the Product Backlog.

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=L_NyCczp0Fk&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.

To review the key ideas of the video:

'''Independent''' – dependencies among or between Stories need to be identified, eliminated, or tracked. An example of dependency: the training video for making a machine cannot be made until the machine is designed.
'''Negotiable''' – the Product Owner and the Team co-create the value and attributes of features (Stories)
'''Valuable''' – all Stories are connected directly to business value.
'''Estimable''' – the Team estimates the size of the Stories relative to each other.
'''Small''' – an important concept is raised here. Stories that are coming up in priority in the first or second Release should be small enough to be finished in one Sprint. Stories that are being implemented later can be large (Epics – more on this below).
'''Testable''' – knowing how we will know the Story is done, also called knowing the Definition of Done.

This review of the qualities of a good User Story gives some idea of the work to be done during Sprint Zero, while the User Stories are created, combined in one list, and then prioritized to make up the Product Backlog.

During Sprint Zero, the Product Owner will create a list of Epics. Epics are very large Stories. An example:
* As OSE, I want complete training materials in English for the 50 tools in GVCS on DVD, so that anyone with moderate experience in fabrication, and with access to the necessary tools and materials, can fabricate any of the 50 tools.

The list of Epics doesn't have to be exhaustive, but it should be thoroughly discussed and described, using the criteria for Stories developed in the video above.

Here are some further questions to be taken up during Sprint Zero:
* Do we have the right people with the right skills? Is there a need for consultants, etc.?

* Given the Epics, the values, and the definitions of done, what sort of work place, tools and technology set up are indicated?

* What is the general approach we are taking? What will be the length of our Sprints? What is the Road Map -- the key release points? How many teams will there be? If there are multiple teams, how will the Scrum Masters and the Product Owners from the multiple teams work together?

At the end of Sprint Zero, the Product Backlog must contain enough prioritized Stories to fill at least the first Release. Ideally, there would be enough Stories for two or three releases, so that the broad outlines of the technology and personnel needed can be understood.

Here's a possible outline for Sprint Zero:
Describe final product
Create a team(s) workspace(s)
Determine the length of sprints
Identify business value (the criteria to measure the value of work as it's done)
Create epics. Prioritize epics (consider relative business value)
For the highest priority epic, turn the epic into stories
Prioritize the stories (consider relative business value)
For each story, create a definition of done

===Definition of Done===

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=9FnZsaRujpw&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
NOTE -- this video is LOUD!

Review of the main concepts of the video:

This video is from Agile; Scrum is one form of Agile. So in this video you don't see mention of a Scrum Master. Instead they talk about a Team Lead. However, the content on Definition of Done is relevant for OSE.

In this video he is discussing creating the Definition of Done at the Team level. The Product Owner needs to first supply the Team with an initial Definition of Done feature by feature. The Product Owner's Definition of Done revolves around the What (and explains the Why). The Team's Definition of Done defines the How.

In the video, he refers to "blockers," which are usually referred to in Scrum as Impediments. More on that later...

One value of this video is that it stresses how all members of a multi-functional Team get involved in creating the Definition of Done. It is crucial that this Definition is agreed to by everyone on the Team. When the Team commits to the work included in a Release, and in each Sprint, they are doing so based on the agreed on Definition of Done for each Story.

There is quite a bit of excess jargon in this video, but have patience, and relate it to GVCS. For example, we not only need to have the machine design "done," but also CAD drawings, an instructional video, and many other instructional components. Unifying the release and "done-ness" of all of these is what seems like the best, and most radical!, contribution Scrum can make to GVCS. These underlying points of “What is Done?” are crucial for us to understand the work that is needed in S0print Zero.

==OSE [[GVCS]] Scrum==

First, we list the projects, in order of priority. See GVCS graphic on the right. Changes are: remove pyrolysis oil and [[Babington burner]] with biomass [[Pelletizer]] for fueling modern [[Steam Engine]]s. The burner is already present in the form of the [[:File:Gasifiericon.jpg|Gasifier Icon]]
[[Image:Slide1Linz7.jpg|thumb|40 [[GVCS]] technologies.]]
#CEB press - [[Full Product Release]] achieved.
#LifeTrac - on Prototype II
#Soil Pulverizer -

==See Also==

* [http://www.scrumhw.org/ Scrum for Hardware Product Development] ''Bringing Scrum to the Hardware Product Development Community''
* [http://maccherone.com/larry/2010/02/23/top-10-questions-when-using-agile-on-hardware-projects/ Top 10 questions when using Agile on hardware projects]

[[Category:Project Management]]

Scrum

2012-03-05T02:53:19Z

Mia Van Meter: /* Definition of Done */

Definition: '''[[wikipedia:Scrum (development)|Scrum]]''' is an iterative and incremental methodology for software projects and product- or application-development. It is also one of the variants of [[wikipedia:agile software development|agile software development]] methodologies.

==Why would a development team use Scrum?==

As demonstrated by high-powered software teams around the world, the Scrum process can increase a development team's efficiency dramatically. In recent years, some Scrum coaches (Scrum Masters) can consistently get development teams to be six times more efficient, and it is becoming almost unremarkable for a Scrum Master to kick a team into a productive state 15 times more productive than in their pre-Scrum days.

The adoption of Scrum by Western development teams is part of a grand mimicking of Japanese manufacturing techniques, which has been going on, with patterns of waxing and waning, for many decades. Software development has become a big enough industry that its leading edge is penetrating many other industries. Its leading edge is the family of development management processes called Agile, one of which, the most popular, is Scrum.

Scrum is essentially a double handful of rules for how a team should work together, and how they should be managed. Underneath those rules is a profound understanding of human nature. What motivates us? That is the essential question which Scrum answers. Scrum rules are designed to instill ownership, motivation, and creative problem-solving in team members. The dramatic results of a well-functioning Scrum team come from the synchronistic multiplying effect of a group of developers working “in the flow.” [http://en.wikipedia.org/wiki/Jeff_Sutherland/ Jeff Sutherland], one of the creators of Scrum, refers to these as “activated” teams.

Following [http://en.wikipedia.org/wiki/Lean_software_development/ Lean] development principles, the rules of Scrum are stripped down to the essentials. One of the implications of this is that teams must adopt all the Scrum rules in order to get Scrum results. Jeff Sutherland's favorite lecture topic seems to be “Scrumbutt.” This occurs when teams say, “Yes, we're doing Scrum, but...” and explain an aspect of Scrum they decided not to implement. According to Sutherland, you cannot get dramatic results unless you are pretty much a Scrum purist. That said, Scrum can “wrap around” other software development process technologies like, for example, XP or Lean. It's not essential to understand those technologies fully, for our purposes, but they are mentioned in the discussion on this page.

The most relevant question for a project like OSE is – is Scrum applicable outside the software development world? This is the answer that Joe Justice and the WikiSpeed team answer with a resounding “Yes!” In the 10-minute TEDX talk below, he explains briefly how the WikiSpeed Team, a collection of 44 volunteers in 4 countries, in three months used Scrum and associated processes to design and build a road-certifiable 4-person commuter car that can get over 100 miles per gallon in standard EPA road tests. The relevance of this to OSE is obvious – a distributed team of volunteers co-developing revolutionary hardware, sound familiar? It's well worth your while to spend a few hours absorbing the information on Scrum that this page points to, and to help explore its relevance for OSE in general, and the GVCS in particular.

In this video, Joe Justice, of WikiSpeed, explains the process his all-volunteer design team used to exceed expectations in their fuel-efficient car design.

<html><iframe width="300" height="182" src="http://www.youtube.com/watch?v=x8jdx-lf2Dw" frameborder="0" allowfullscreen></iframe></html>

.
.

.
.

==What is Scrum?==

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/watch?v=Q5k7a9YEoUI" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
The video above is a great first introduction to Scrum! It's fast paced, and the graphics easily convey the important information.

Of course, like any single Scrum coach, this one has his own take on Scrum, and in some instances it's likely that OSE Scrum will be different.

To review his core concepts:

Roles: Product Owner, Scrum Master, Team Members (developers, testers, customers)

Release Planning:
Product Backlog– Estimate for each feature wanted in product.
Release Backlog
plan 4-12 Sprints – a substantive back log to a ship-ready state
Sprint Backlog

Burndown Chart – day by day measure of the amount of work left in a Release, or Sprint

Bugs – have a separate Defect Backlog. Resolve bugs within the Sprint.

Daily Scrum – short, standing, identify bugs.

So that video is a great introduction to Scrum, but how would we actually get started?

The Scrum process starts with the Product Owner. They are responsible for creating the Product Backlog, creating the Development Team, and for providing the Team with the tools necessary for them to work. The Scrum Master helps the Product Owner with these tasks.

===Sprint ZERO===

To get ready for the first development Sprint, the Product Owner and the Scrum Master need to meet together, and with the Team, and do some initial preparation. The amount of time spent on Sprint Zero should be limited, and agreed upon in advance. Unfinished preparation can be added to the Product Backlog when Sprint Zero is finished. Additionally, the task of adding to the Product Backlog, and refining features that are down the road a bit, will be ongoing tasks for the Product Owner.

The most important outcome of Sprint Zero is to create understanding about the value of the work. Given that OSE might choose to have a team (Scrum) of Product Owners, it could make implementation more clear if the business values we are creating are explicitly ranked. Usually the process of identifying and clarifying the business value is held more distantly from the Team. In the case of OSE, it seems likely that a group of people will be determining the relative priorities of our business values, and the relative rankings of the features that we're planning on creating.

We've been talking about ranking the features that make up the Product Backlog. In Scrum, these features are called Stories. There is an art to defining a Scrum Story, as you might imagine. Stories often take this form:

As _[User]_____, I want _[feature]_______, so that __[value]______.

An example:

* As a fabricator making a CNC Torch Table, I want complete and accurate CAD drawings, so that my efforts will result in a well-functioning machine.

Because the User is included in defining the feature, these are known as User Stories. The following video explains a good way to evaluate and improve User Stories, which are the list of features that make up the Product Backlog.

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=L_NyCczp0Fk&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.

To review the key ideas of the video:

'''Independent''' – dependencies among or between Stories need to be identified, eliminated, or tracked. An example of dependency: the training video for making a machine cannot be made until the machine is designed.
'''Negotiable''' – the Product Owner and the Team co-create the value and attributes of features (Stories)
'''Valuable''' – all Stories are connected directly to business value.
'''Estimable''' – the Team estimates the size of the Stories relative to each other.
'''Small''' – an important concept is raised here. Stories that are coming up in priority in the first or second Release should be small enough to be finished in one Sprint. Stories that are being implemented later can be large (Epics – more on this below).
'''Testable''' – knowing how we will know the Story is done, also called knowing the Definition of Done.

This review of the qualities of a good User Story gives some idea of the work to be done during Sprint Zero, while the User Stories are created, combined in one list, and then prioritized to make up the Product Backlog.

During Sprint Zero, the Product Owner will create a list of Epics. Epics are very large Stories. An example:
* As OSE, I want complete training materials in English for the 50 tools in GVCS on DVD, so that anyone with moderate experience in fabrication, and with access to the necessary tools and materials, can fabricate any of the 50 tools.

The list of Epics doesn't have to be exhaustive, but it should be thoroughly discussed and described, using the criteria for Stories developed in the video above.

Here are some further questions to be taken up during Sprint Zero:
* Do we have the right people with the right skills? Is there a need for consultants, etc.?

* Given the Epics, the values, and the definitions of done, what sort of work place, tools and technology set up are indicated?

* What is the general approach we are taking? What will be the length of our Sprints? What is the Road Map -- the key release points? How many teams will there be? If there are multiple teams, how will the Scrum Masters and the Product Owners from the multiple teams work together?

At the end of Sprint Zero, the Product Backlog must contain enough prioritized Stories to fill at least the first Release. Ideally, there would be enough Stories for two or three releases, so that the broad outlines of the technology and personnel needed can be understood.

Here's a possible outline for Sprint Zero:
Describe final product
Create a team(s) workspace(s)
Determine the length of sprints
Identify business value (the criteria to measure the value of work as it's done)
Create epics. Prioritize epics (consider relative business value)
For the highest priority epic, turn the epic into stories
Prioritize the stories (consider relative business value)
For each story, create a definition of done

===Definition of Done===

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=9FnZsaRujpw&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
NOTE -- this video is LOUD!

Review of the main concepts of the video:
0
This video is from Agile; Scrum is one form of Agile. So in this video you don't see mention of a Scrum Master. Instead they talk about a Team Lead. However, the content on Definition of Done is relevant for OSE.

In this video he is discussing creating the Definition of Done at the Team level. The Product Owner needs to first supply the Team with an initial Definition of Done feature by feature. The Product Owner's Definition of Done revolves around the What (and explains the Why). The Team's Definition of Done defines the How.

In the video, he refers to "blockers," which are usually referred to in Scrum as Impediments. More on that later...

One value of this video is that it stresses how all members of a multi-functional Team get involved in creating the Definition of Done. It is crucial that this Definition is agreed to by everyone on the Team. When the Team commits to the work included in a Release, and in each Sprint, they are doing so based on the agreed on Definition of Done for each Story.

There is quite a bit of excess jargon in this video, but have patience, and relate it to GVCS. For example, we not only need to have the machine design "done," but also CAD drawings, an instructional video, and many other instructional components. Unifying the release and "done-ness" of all of these is what seems like the best, and most radical!, contribution Scrum can make to GVCS. These underlying points of “What is Done?” are crucial for us to understand the work that is needed in S0print Zero.

==OSE [[GVCS]] Scrum==

First, we list the projects, in order of priority. See GVCS graphic on the right. Changes are: remove pyrolysis oil and [[Babington burner]] with biomass [[Pelletizer]] for fueling modern [[Steam Engine]]s. The burner is already present in the form of the [[:File:Gasifiericon.jpg|Gasifier Icon]]
[[Image:Slide1Linz7.jpg|thumb|40 [[GVCS]] technologies.]]
#CEB press - [[Full Product Release]] achieved.
#LifeTrac - on Prototype II
#Soil Pulverizer -

==See Also==

* [http://www.scrumhw.org/ Scrum for Hardware Product Development] ''Bringing Scrum to the Hardware Product Development Community''
* [http://maccherone.com/larry/2010/02/23/top-10-questions-when-using-agile-on-hardware-projects/ Top 10 questions when using Agile on hardware projects]

[[Category:Project Management]]

Scrum

2012-03-05T02:51:42Z

Mia Van Meter: /* Definition of Done */ rewrite of section

Definition: '''[[wikipedia:Scrum (development)|Scrum]]''' is an iterative and incremental methodology for software projects and product- or application-development. It is also one of the variants of [[wikipedia:agile software development|agile software development]] methodologies.

==Why would a development team use Scrum?==

As demonstrated by high-powered software teams around the world, the Scrum process can increase a development team's efficiency dramatically. In recent years, some Scrum coaches (Scrum Masters) can consistently get development teams to be six times more efficient, and it is becoming almost unremarkable for a Scrum Master to kick a team into a productive state 15 times more productive than in their pre-Scrum days.

The adoption of Scrum by Western development teams is part of a grand mimicking of Japanese manufacturing techniques, which has been going on, with patterns of waxing and waning, for many decades. Software development has become a big enough industry that its leading edge is penetrating many other industries. Its leading edge is the family of development management processes called Agile, one of which, the most popular, is Scrum.

Scrum is essentially a double handful of rules for how a team should work together, and how they should be managed. Underneath those rules is a profound understanding of human nature. What motivates us? That is the essential question which Scrum answers. Scrum rules are designed to instill ownership, motivation, and creative problem-solving in team members. The dramatic results of a well-functioning Scrum team come from the synchronistic multiplying effect of a group of developers working “in the flow.” [http://en.wikipedia.org/wiki/Jeff_Sutherland/ Jeff Sutherland], one of the creators of Scrum, refers to these as “activated” teams.

Following [http://en.wikipedia.org/wiki/Lean_software_development/ Lean] development principles, the rules of Scrum are stripped down to the essentials. One of the implications of this is that teams must adopt all the Scrum rules in order to get Scrum results. Jeff Sutherland's favorite lecture topic seems to be “Scrumbutt.” This occurs when teams say, “Yes, we're doing Scrum, but...” and explain an aspect of Scrum they decided not to implement. According to Sutherland, you cannot get dramatic results unless you are pretty much a Scrum purist. That said, Scrum can “wrap around” other software development process technologies like, for example, XP or Lean. It's not essential to understand those technologies fully, for our purposes, but they are mentioned in the discussion on this page.

The most relevant question for a project like OSE is – is Scrum applicable outside the software development world? This is the answer that Joe Justice and the WikiSpeed team answer with a resounding “Yes!” In the 10-minute TEDX talk below, he explains briefly how the WikiSpeed Team, a collection of 44 volunteers in 4 countries, in three months used Scrum and associated processes to design and build a road-certifiable 4-person commuter car that can get over 100 miles per gallon in standard EPA road tests. The relevance of this to OSE is obvious – a distributed team of volunteers co-developing revolutionary hardware, sound familiar? It's well worth your while to spend a few hours absorbing the information on Scrum that this page points to, and to help explore its relevance for OSE in general, and the GVCS in particular.

In this video, Joe Justice, of WikiSpeed, explains the process his all-volunteer design team used to exceed expectations in their fuel-efficient car design.

<html><iframe width="300" height="182" src="http://www.youtube.com/watch?v=x8jdx-lf2Dw" frameborder="0" allowfullscreen></iframe></html>

.
.

.
.

==What is Scrum?==

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/watch?v=Q5k7a9YEoUI" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
The video above is a great first introduction to Scrum! It's fast paced, and the graphics easily convey the important information.

Of course, like any single Scrum coach, this one has his own take on Scrum, and in some instances it's likely that OSE Scrum will be different.

To review his core concepts:

Roles: Product Owner, Scrum Master, Team Members (developers, testers, customers)

Release Planning:
Product Backlog– Estimate for each feature wanted in product.
Release Backlog
plan 4-12 Sprints – a substantive back log to a ship-ready state
Sprint Backlog

Burndown Chart – day by day measure of the amount of work left in a Release, or Sprint

Bugs – have a separate Defect Backlog. Resolve bugs within the Sprint.

Daily Scrum – short, standing, identify bugs.

So that video is a great introduction to Scrum, but how would we actually get started?

The Scrum process starts with the Product Owner. They are responsible for creating the Product Backlog, creating the Development Team, and for providing the Team with the tools necessary for them to work. The Scrum Master helps the Product Owner with these tasks.

===Sprint ZERO===

To get ready for the first development Sprint, the Product Owner and the Scrum Master need to meet together, and with the Team, and do some initial preparation. The amount of time spent on Sprint Zero should be limited, and agreed upon in advance. Unfinished preparation can be added to the Product Backlog when Sprint Zero is finished. Additionally, the task of adding to the Product Backlog, and refining features that are down the road a bit, will be ongoing tasks for the Product Owner.

The most important outcome of Sprint Zero is to create understanding about the value of the work. Given that OSE might choose to have a team (Scrum) of Product Owners, it could make implementation more clear if the business values we are creating are explicitly ranked. Usually the process of identifying and clarifying the business value is held more distantly from the Team. In the case of OSE, it seems likely that a group of people will be determining the relative priorities of our business values, and the relative rankings of the features that we're planning on creating.

We've been talking about ranking the features that make up the Product Backlog. In Scrum, these features are called Stories. There is an art to defining a Scrum Story, as you might imagine. Stories often take this form:

As _[User]_____, I want _[feature]_______, so that __[value]______.

An example:

* As a fabricator making a CNC Torch Table, I want complete and accurate CAD drawings, so that my efforts will result in a well-functioning machine.

Because the User is included in defining the feature, these are known as User Stories. The following video explains a good way to evaluate and improve User Stories, which are the list of features that make up the Product Backlog.

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=L_NyCczp0Fk&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.

To review the key ideas of the video:

'''Independent''' – dependencies among or between Stories need to be identified, eliminated, or tracked. An example of dependency: the training video for making a machine cannot be made until the machine is designed.
'''Negotiable''' – the Product Owner and the Team co-create the value and attributes of features (Stories)
'''Valuable''' – all Stories are connected directly to business value.
'''Estimable''' – the Team estimates the size of the Stories relative to each other.
'''Small''' – an important concept is raised here. Stories that are coming up in priority in the first or second Release should be small enough to be finished in one Sprint. Stories that are being implemented later can be large (Epics – more on this below).
'''Testable''' – knowing how we will know the Story is done, also called knowing the Definition of Done.

This review of the qualities of a good User Story gives some idea of the work to be done during Sprint Zero, while the User Stories are created, combined in one list, and then prioritized to make up the Product Backlog.

During Sprint Zero, the Product Owner will create a list of Epics. Epics are very large Stories. An example:
* As OSE, I want complete training materials in English for the 50 tools in GVCS on DVD, so that anyone with moderate experience in fabrication, and with access to the necessary tools and materials, can fabricate any of the 50 tools.

The list of Epics doesn't have to be exhaustive, but it should be thoroughly discussed and described, using the criteria for Stories developed in the video above.

Here are some further questions to be taken up during Sprint Zero:
* Do we have the right people with the right skills? Is there a need for consultants, etc.?

* Given the Epics, the values, and the definitions of done, what sort of work place, tools and technology set up are indicated?

* What is the general approach we are taking? What will be the length of our Sprints? What is the Road Map -- the key release points? How many teams will there be? If there are multiple teams, how will the Scrum Masters and the Product Owners from the multiple teams work together?

At the end of Sprint Zero, the Product Backlog must contain enough prioritized Stories to fill at least the first Release. Ideally, there would be enough Stories for two or three releases, so that the broad outlines of the technology and personnel needed can be understood.

Here's a possible outline for Sprint Zero:
Describe final product
Create a team(s) workspace(s)
Determine the length of sprints
Identify business value (the criteria to measure the value of work as it's done)
Create epics. Prioritize epics (consider relative business value)
For the highest priority epic, turn the epic into stories
Prioritize the stories (consider relative business value)
For each story, create a definition of done

===Definition of Done===

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=9FnZsaRujpw&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
NOTE -- this video is LOUD!

Review of the main concepts of the video:
This video is from Agile; Scrum is one form of Agile. So in this video you don't see mention of a Scrum Master. Instead they talk about a Team Lead. However, the content on Definition of Done is relevant for OSE.
In this video he is discussing creating the Definition of Done at the Team level. The Product Owner needs to first supply the Team with an initial Definition of Done feature by feature. The Product Owner's Definition of Done revolves around the What (and explains the Why). The Team's Definition of Done defines the How.
In the video, he refers to "blockers," which are usually referred to in Scrum as Impediments.
One value of this video is that it stresses how all members of a multi-functional Team get involved in creating the Definition of Done. It is crucial that this Definition is agreed to by everyone on the Team. When the Team commits to the work included in a Release, and in each Sprint, they are doing so based on the agreed on Definition of Done for each Story.
There is quite a bit of excess jargon in this video, but have patience, and relate it to GVCS. For example, we not only need to have the machine design "done," but also CAD drawings, an instructional video, and many other instructional components. Unifying the release and "done-ness" of all of these is what seems like the best, and most radical!, contribution Scrum can make to GVCS. These underlying points of “What is Done?” are crucial for us to understand what is needed in sprint Zero.

==OSE [[GVCS]] Scrum==

First, we list the projects, in order of priority. See GVCS graphic on the right. Changes are: remove pyrolysis oil and [[Babington burner]] with biomass [[Pelletizer]] for fueling modern [[Steam Engine]]s. The burner is already present in the form of the [[:File:Gasifiericon.jpg|Gasifier Icon]]
[[Image:Slide1Linz7.jpg|thumb|40 [[GVCS]] technologies.]]
#CEB press - [[Full Product Release]] achieved.
#LifeTrac - on Prototype II
#Soil Pulverizer -

==See Also==

* [http://www.scrumhw.org/ Scrum for Hardware Product Development] ''Bringing Scrum to the Hardware Product Development Community''
* [http://maccherone.com/larry/2010/02/23/top-10-questions-when-using-agile-on-hardware-projects/ Top 10 questions when using Agile on hardware projects]

[[Category:Project Management]]

Scrum

2012-03-05T02:38:03Z

Mia Van Meter: /* Sprint ZERO */ Add summary of Sprint Zero

Definition: '''[[wikipedia:Scrum (development)|Scrum]]''' is an iterative and incremental methodology for software projects and product- or application-development. It is also one of the variants of [[wikipedia:agile software development|agile software development]] methodologies.

==Why would a development team use Scrum?==

As demonstrated by high-powered software teams around the world, the Scrum process can increase a development team's efficiency dramatically. In recent years, some Scrum coaches (Scrum Masters) can consistently get development teams to be six times more efficient, and it is becoming almost unremarkable for a Scrum Master to kick a team into a productive state 15 times more productive than in their pre-Scrum days.

The adoption of Scrum by Western development teams is part of a grand mimicking of Japanese manufacturing techniques, which has been going on, with patterns of waxing and waning, for many decades. Software development has become a big enough industry that its leading edge is penetrating many other industries. Its leading edge is the family of development management processes called Agile, one of which, the most popular, is Scrum.

Scrum is essentially a double handful of rules for how a team should work together, and how they should be managed. Underneath those rules is a profound understanding of human nature. What motivates us? That is the essential question which Scrum answers. Scrum rules are designed to instill ownership, motivation, and creative problem-solving in team members. The dramatic results of a well-functioning Scrum team come from the synchronistic multiplying effect of a group of developers working “in the flow.” [http://en.wikipedia.org/wiki/Jeff_Sutherland/ Jeff Sutherland], one of the creators of Scrum, refers to these as “activated” teams.

Following [http://en.wikipedia.org/wiki/Lean_software_development/ Lean] development principles, the rules of Scrum are stripped down to the essentials. One of the implications of this is that teams must adopt all the Scrum rules in order to get Scrum results. Jeff Sutherland's favorite lecture topic seems to be “Scrumbutt.” This occurs when teams say, “Yes, we're doing Scrum, but...” and explain an aspect of Scrum they decided not to implement. According to Sutherland, you cannot get dramatic results unless you are pretty much a Scrum purist. That said, Scrum can “wrap around” other software development process technologies like, for example, XP or Lean. It's not essential to understand those technologies fully, for our purposes, but they are mentioned in the discussion on this page.

The most relevant question for a project like OSE is – is Scrum applicable outside the software development world? This is the answer that Joe Justice and the WikiSpeed team answer with a resounding “Yes!” In the 10-minute TEDX talk below, he explains briefly how the WikiSpeed Team, a collection of 44 volunteers in 4 countries, in three months used Scrum and associated processes to design and build a road-certifiable 4-person commuter car that can get over 100 miles per gallon in standard EPA road tests. The relevance of this to OSE is obvious – a distributed team of volunteers co-developing revolutionary hardware, sound familiar? It's well worth your while to spend a few hours absorbing the information on Scrum that this page points to, and to help explore its relevance for OSE in general, and the GVCS in particular.

In this video, Joe Justice, of WikiSpeed, explains the process his all-volunteer design team used to exceed expectations in their fuel-efficient car design.

<html><iframe width="300" height="182" src="http://www.youtube.com/watch?v=x8jdx-lf2Dw" frameborder="0" allowfullscreen></iframe></html>

.
.

.
.

==What is Scrum?==

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/watch?v=Q5k7a9YEoUI" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
The video above is a great first introduction to Scrum! It's fast paced, and the graphics easily convey the important information.

Of course, like any single Scrum coach, this one has his own take on Scrum, and in some instances it's likely that OSE Scrum will be different.

To review his core concepts:

Roles: Product Owner, Scrum Master, Team Members (developers, testers, customers)

Release Planning:
Product Backlog– Estimate for each feature wanted in product.
Release Backlog
plan 4-12 Sprints – a substantive back log to a ship-ready state
Sprint Backlog

Burndown Chart – day by day measure of the amount of work left in a Release, or Sprint

Bugs – have a separate Defect Backlog. Resolve bugs within the Sprint.

Daily Scrum – short, standing, identify bugs.

So that video is a great introduction to Scrum, but how would we actually get started?

The Scrum process starts with the Product Owner. They are responsible for creating the Product Backlog, creating the Development Team, and for providing the Team with the tools necessary for them to work. The Scrum Master helps the Product Owner with these tasks.

===Sprint ZERO===

To get ready for the first development Sprint, the Product Owner and the Scrum Master need to meet together, and with the Team, and do some initial preparation. The amount of time spent on Sprint Zero should be limited, and agreed upon in advance. Unfinished preparation can be added to the Product Backlog when Sprint Zero is finished. Additionally, the task of adding to the Product Backlog, and refining features that are down the road a bit, will be ongoing tasks for the Product Owner.

The most important outcome of Sprint Zero is to create understanding about the value of the work. Given that OSE might choose to have a team (Scrum) of Product Owners, it could make implementation more clear if the business values we are creating are explicitly ranked. Usually the process of identifying and clarifying the business value is held more distantly from the Team. In the case of OSE, it seems likely that a group of people will be determining the relative priorities of our business values, and the relative rankings of the features that we're planning on creating.

We've been talking about ranking the features that make up the Product Backlog. In Scrum, these features are called Stories. There is an art to defining a Scrum Story, as you might imagine. Stories often take this form:

As _[User]_____, I want _[feature]_______, so that __[value]______.

An example:

* As a fabricator making a CNC Torch Table, I want complete and accurate CAD drawings, so that my efforts will result in a well-functioning machine.

Because the User is included in defining the feature, these are known as User Stories. The following video explains a good way to evaluate and improve User Stories, which are the list of features that make up the Product Backlog.

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=L_NyCczp0Fk&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.

To review the key ideas of the video:

'''Independent''' – dependencies among or between Stories need to be identified, eliminated, or tracked. An example of dependency: the training video for making a machine cannot be made until the machine is designed.
'''Negotiable''' – the Product Owner and the Team co-create the value and attributes of features (Stories)
'''Valuable''' – all Stories are connected directly to business value.
'''Estimable''' – the Team estimates the size of the Stories relative to each other.
'''Small''' – an important concept is raised here. Stories that are coming up in priority in the first or second Release should be small enough to be finished in one Sprint. Stories that are being implemented later can be large (Epics – more on this below).
'''Testable''' – knowing how we will know the Story is done, also called knowing the Definition of Done.

This review of the qualities of a good User Story gives some idea of the work to be done during Sprint Zero, while the User Stories are created, combined in one list, and then prioritized to make up the Product Backlog.

During Sprint Zero, the Product Owner will create a list of Epics. Epics are very large Stories. An example:
* As OSE, I want complete training materials in English for the 50 tools in GVCS on DVD, so that anyone with moderate experience in fabrication, and with access to the necessary tools and materials, can fabricate any of the 50 tools.

The list of Epics doesn't have to be exhaustive, but it should be thoroughly discussed and described, using the criteria for Stories developed in the video above.

Here are some further questions to be taken up during Sprint Zero:
* Do we have the right people with the right skills? Is there a need for consultants, etc.?

* Given the Epics, the values, and the definitions of done, what sort of work place, tools and technology set up are indicated?

* What is the general approach we are taking? What will be the length of our Sprints? What is the Road Map -- the key release points? How many teams will there be? If there are multiple teams, how will the Scrum Masters and the Product Owners from the multiple teams work together?

At the end of Sprint Zero, the Product Backlog must contain enough prioritized Stories to fill at least the first Release. Ideally, there would be enough Stories for two or three releases, so that the broad outlines of the technology and personnel needed can be understood.

Here's a possible outline for Sprint Zero:
Describe final product
Create a team(s) workspace(s)
Determine the length of sprints
Identify business value (the criteria to measure the value of work as it's done)
Create epics. Prioritize epics (consider relative business value)
For the highest priority epic, turn the epic into stories
Prioritize the stories (consider relative business value)
For each story, create a definition of done

===Definition of Done===

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=9FnZsaRujpw&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
NOTE -- this video is LOUD!

Definition of Done:
In the video, he refers to "blockers" which are impediments. There is quite a bit of excess jargon in this video, but have patience, and relate it to GVCS. For example, we not only need to have the machine design "done," but also CAD drawings, an instructional video, and many other instructional components. Unifying the release and "done-ness" of all of these is what seems like the best, and most radical!, contribution Scrum can make to GVCS. These underlying points are crucial for us to understand what is needed in Iteration Zero. See discussion of a trial run-through by Simon and Mia below for more on this.

As the first Release progresses, the Product Owner and the Scrum Master will continue to develop the Product Backlog in preparation for the next Release. By the start of the second Release, there will need to be enough prioritized Stories (including Impediment Resolutions and Technology Spikes) for that Release.

Describing final product

The vision of the final outcome will continually change, and this adaptability is what Scrum is designed for. To minimize too much front-loading of visioning work, focus your vision on the next product version, and envision a product with minimum functionality that addresses a narrow set of customer needs. Quickly release a first product increment, or demo it to customers and users to validate the vision. Listen to the responses to see if you are shooting for the right goal. Then adapt.

Selectively describes the product at a coarse-grained level, capturing the product’s essence. Answer the following questions:
• Who are the product's target users?
• Which needs will the product address? What value does the product add?
• Which product attributes are critical for meeting the needs selected and therefore for the success of the product? What will the product roughly look like and do? In which areas is the product going to excel?
• What are the sources of revenue and what is the business model?

To what extent should a few of these processes be pulled into the normal Sprints?

==OSE [[GVCS]] Scrum==

First, we list the projects, in order of priority. See GVCS graphic on the right. Changes are: remove pyrolysis oil and [[Babington burner]] with biomass [[Pelletizer]] for fueling modern [[Steam Engine]]s. The burner is already present in the form of the [[:File:Gasifiericon.jpg|Gasifier Icon]]
[[Image:Slide1Linz7.jpg|thumb|40 [[GVCS]] technologies.]]
#CEB press - [[Full Product Release]] achieved.
#LifeTrac - on Prototype II
#Soil Pulverizer -

==See Also==

* [http://www.scrumhw.org/ Scrum for Hardware Product Development] ''Bringing Scrum to the Hardware Product Development Community''
* [http://maccherone.com/larry/2010/02/23/top-10-questions-when-using-agile-on-hardware-projects/ Top 10 questions when using Agile on hardware projects]

[[Category:Project Management]]

Scrum

2012-03-05T02:37:16Z

Mia Van Meter: /* Definition of Done */

Definition: '''[[wikipedia:Scrum (development)|Scrum]]''' is an iterative and incremental methodology for software projects and product- or application-development. It is also one of the variants of [[wikipedia:agile software development|agile software development]] methodologies.

==Why would a development team use Scrum?==

As demonstrated by high-powered software teams around the world, the Scrum process can increase a development team's efficiency dramatically. In recent years, some Scrum coaches (Scrum Masters) can consistently get development teams to be six times more efficient, and it is becoming almost unremarkable for a Scrum Master to kick a team into a productive state 15 times more productive than in their pre-Scrum days.

The adoption of Scrum by Western development teams is part of a grand mimicking of Japanese manufacturing techniques, which has been going on, with patterns of waxing and waning, for many decades. Software development has become a big enough industry that its leading edge is penetrating many other industries. Its leading edge is the family of development management processes called Agile, one of which, the most popular, is Scrum.

Scrum is essentially a double handful of rules for how a team should work together, and how they should be managed. Underneath those rules is a profound understanding of human nature. What motivates us? That is the essential question which Scrum answers. Scrum rules are designed to instill ownership, motivation, and creative problem-solving in team members. The dramatic results of a well-functioning Scrum team come from the synchronistic multiplying effect of a group of developers working “in the flow.” [http://en.wikipedia.org/wiki/Jeff_Sutherland/ Jeff Sutherland], one of the creators of Scrum, refers to these as “activated” teams.

Following [http://en.wikipedia.org/wiki/Lean_software_development/ Lean] development principles, the rules of Scrum are stripped down to the essentials. One of the implications of this is that teams must adopt all the Scrum rules in order to get Scrum results. Jeff Sutherland's favorite lecture topic seems to be “Scrumbutt.” This occurs when teams say, “Yes, we're doing Scrum, but...” and explain an aspect of Scrum they decided not to implement. According to Sutherland, you cannot get dramatic results unless you are pretty much a Scrum purist. That said, Scrum can “wrap around” other software development process technologies like, for example, XP or Lean. It's not essential to understand those technologies fully, for our purposes, but they are mentioned in the discussion on this page.

The most relevant question for a project like OSE is – is Scrum applicable outside the software development world? This is the answer that Joe Justice and the WikiSpeed team answer with a resounding “Yes!” In the 10-minute TEDX talk below, he explains briefly how the WikiSpeed Team, a collection of 44 volunteers in 4 countries, in three months used Scrum and associated processes to design and build a road-certifiable 4-person commuter car that can get over 100 miles per gallon in standard EPA road tests. The relevance of this to OSE is obvious – a distributed team of volunteers co-developing revolutionary hardware, sound familiar? It's well worth your while to spend a few hours absorbing the information on Scrum that this page points to, and to help explore its relevance for OSE in general, and the GVCS in particular.

In this video, Joe Justice, of WikiSpeed, explains the process his all-volunteer design team used to exceed expectations in their fuel-efficient car design.

<html><iframe width="300" height="182" src="http://www.youtube.com/watch?v=x8jdx-lf2Dw" frameborder="0" allowfullscreen></iframe></html>

.
.

.
.

==What is Scrum?==

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/watch?v=Q5k7a9YEoUI" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
The video above is a great first introduction to Scrum! It's fast paced, and the graphics easily convey the important information.

Of course, like any single Scrum coach, this one has his own take on Scrum, and in some instances it's likely that OSE Scrum will be different.

To review his core concepts:

Roles: Product Owner, Scrum Master, Team Members (developers, testers, customers)

Release Planning:
Product Backlog– Estimate for each feature wanted in product.
Release Backlog
plan 4-12 Sprints – a substantive back log to a ship-ready state
Sprint Backlog

Burndown Chart – day by day measure of the amount of work left in a Release, or Sprint

Bugs – have a separate Defect Backlog. Resolve bugs within the Sprint.

Daily Scrum – short, standing, identify bugs.

So that video is a great introduction to Scrum, but how would we actually get started?

The Scrum process starts with the Product Owner. They are responsible for creating the Product Backlog, creating the Development Team, and for providing the Team with the tools necessary for them to work. The Scrum Master helps the Product Owner with these tasks.

===Sprint ZERO===

To get ready for the first development Sprint, the Product Owner and the Scrum Master need to meet together, and with the Team, and do some initial preparation. The amount of time spent on Sprint Zero should be limited, and agreed upon in advance. Unfinished preparation can be added to the Product Backlog when Sprint Zero is finished. Additionally, the task of adding to the Product Backlog, and refining features that are down the road a bit, will be ongoing tasks for the Product Owner.

The most important outcome of Sprint Zero is to create understanding about the value of the work. Given that OSE might choose to have a team (Scrum) of Product Owners, it could make implementation more clear if the business values we are creating are explicitly ranked. Usually the process of identifying and clarifying the business value is held more distantly from the Team. In the case of OSE, it seems likely that a group of people will be determining the relative priorities of our business values, and the relative rankings of the features that we're planning on creating.

We've been talking about ranking the features that make up the Product Backlog. In Scrum, these features are called Stories. There is an art to defining a Scrum Story, as you might imagine. Stories often take this form:

As _[User]_____, I want _[feature]_______, so that __[value]______.

An example:

* As a fabricator making a CNC Torch Table, I want complete and accurate CAD drawings, so that my efforts will result in a well-functioning machine.

Because the User is included in defining the feature, these are known as User Stories. The following video explains a good way to evaluate and improve User Stories, which are the list of features that make up the Product Backlog.

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=L_NyCczp0Fk&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.

To review the key ideas of the video:

'''Independent''' – dependencies among or between Stories need to be identified, eliminated, or tracked. An example of dependency: the training video for making a machine cannot be made until the machine is designed.
'''Negotiable''' – the Product Owner and the Team co-create the value and attributes of features (Stories)
'''Valuable''' – all Stories are connected directly to business value.
'''Estimable''' – the Team estimates the size of the Stories relative to each other.
'''Small''' – an important concept is raised here. Stories that are coming up in priority in the first or second Release should be small enough to be finished in one Sprint. Stories that are being implemented later can be large (Epics – more on this below).
'''Testable''' – knowing how we will know the Story is done, also called knowing the Definition of Done.

This review of the qualities of a good User Story gives some idea of the work to be done during Sprint Zero, while the User Stories are created, combined in one list, and then prioritized to make up the Product Backlog.

During Sprint Zero, the Product Owner will create a list of Epics. Epics are very large Stories. An example:
* As OSE, I want complete training materials in English for the 50 tools in GVCS on DVD, so that anyone with moderate experience in fabrication, and with access to the necessary tools and materials, can fabricate any of the 50 tools.

The list of Epics doesn't have to be exhaustive, but it should be thoroughly discussed and described, using the criteria for Stories developed in the video above.

Here are some further questions to be taken up during Sprint Zero:
* Do we have the right people with the right skills? Is there a need for consultants, etc.?

* Given the Epics, the values, and the definitions of done, what sort of work place, tools and technology set up are indicated?

* What is the general approach we are taking? What will be the length of our Sprints? What is the Road Map -- the key release points? How many teams will there be? If there are multiple teams, how will the Scrum Masters and the Product Owners from the multiple teams work together?

At the end of Sprint Zero, the Product Backlog must contain enough prioritized Stories to fill at least the first Release. Ideally, there would be enough Stories for two or three releases, so that the broad outlines of the technology and personnel needed can be understood.

===Definition of Done===

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=9FnZsaRujpw&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
NOTE -- this video is LOUD!

Definition of Done:
In the video, he refers to "blockers" which are impediments. There is quite a bit of excess jargon in this video, but have patience, and relate it to GVCS. For example, we not only need to have the machine design "done," but also CAD drawings, an instructional video, and many other instructional components. Unifying the release and "done-ness" of all of these is what seems like the best, and most radical!, contribution Scrum can make to GVCS. These underlying points are crucial for us to understand what is needed in Iteration Zero. See discussion of a trial run-through by Simon and Mia below for more on this.

As the first Release progresses, the Product Owner and the Scrum Master will continue to develop the Product Backlog in preparation for the next Release. By the start of the second Release, there will need to be enough prioritized Stories (including Impediment Resolutions and Technology Spikes) for that Release.

Describing final product

The vision of the final outcome will continually change, and this adaptability is what Scrum is designed for. To minimize too much front-loading of visioning work, focus your vision on the next product version, and envision a product with minimum functionality that addresses a narrow set of customer needs. Quickly release a first product increment, or demo it to customers and users to validate the vision. Listen to the responses to see if you are shooting for the right goal. Then adapt.

Selectively describes the product at a coarse-grained level, capturing the product’s essence. Answer the following questions:
• Who are the product's target users?
• Which needs will the product address? What value does the product add?
• Which product attributes are critical for meeting the needs selected and therefore for the success of the product? What will the product roughly look like and do? In which areas is the product going to excel?
• What are the sources of revenue and what is the business model?

To what extent should a few of these processes be pulled into the normal Sprints?

==OSE [[GVCS]] Scrum==

First, we list the projects, in order of priority. See GVCS graphic on the right. Changes are: remove pyrolysis oil and [[Babington burner]] with biomass [[Pelletizer]] for fueling modern [[Steam Engine]]s. The burner is already present in the form of the [[:File:Gasifiericon.jpg|Gasifier Icon]]
[[Image:Slide1Linz7.jpg|thumb|40 [[GVCS]] technologies.]]
#CEB press - [[Full Product Release]] achieved.
#LifeTrac - on Prototype II
#Soil Pulverizer -

==See Also==

* [http://www.scrumhw.org/ Scrum for Hardware Product Development] ''Bringing Scrum to the Hardware Product Development Community''
* [http://maccherone.com/larry/2010/02/23/top-10-questions-when-using-agile-on-hardware-projects/ Top 10 questions when using Agile on hardware projects]

[[Category:Project Management]]

Scrum

2012-03-05T02:35:24Z

Mia Van Meter: /* Sprint ZERO */

Definition: '''[[wikipedia:Scrum (development)|Scrum]]''' is an iterative and incremental methodology for software projects and product- or application-development. It is also one of the variants of [[wikipedia:agile software development|agile software development]] methodologies.

==Why would a development team use Scrum?==

As demonstrated by high-powered software teams around the world, the Scrum process can increase a development team's efficiency dramatically. In recent years, some Scrum coaches (Scrum Masters) can consistently get development teams to be six times more efficient, and it is becoming almost unremarkable for a Scrum Master to kick a team into a productive state 15 times more productive than in their pre-Scrum days.

The adoption of Scrum by Western development teams is part of a grand mimicking of Japanese manufacturing techniques, which has been going on, with patterns of waxing and waning, for many decades. Software development has become a big enough industry that its leading edge is penetrating many other industries. Its leading edge is the family of development management processes called Agile, one of which, the most popular, is Scrum.

Scrum is essentially a double handful of rules for how a team should work together, and how they should be managed. Underneath those rules is a profound understanding of human nature. What motivates us? That is the essential question which Scrum answers. Scrum rules are designed to instill ownership, motivation, and creative problem-solving in team members. The dramatic results of a well-functioning Scrum team come from the synchronistic multiplying effect of a group of developers working “in the flow.” [http://en.wikipedia.org/wiki/Jeff_Sutherland/ Jeff Sutherland], one of the creators of Scrum, refers to these as “activated” teams.

Following [http://en.wikipedia.org/wiki/Lean_software_development/ Lean] development principles, the rules of Scrum are stripped down to the essentials. One of the implications of this is that teams must adopt all the Scrum rules in order to get Scrum results. Jeff Sutherland's favorite lecture topic seems to be “Scrumbutt.” This occurs when teams say, “Yes, we're doing Scrum, but...” and explain an aspect of Scrum they decided not to implement. According to Sutherland, you cannot get dramatic results unless you are pretty much a Scrum purist. That said, Scrum can “wrap around” other software development process technologies like, for example, XP or Lean. It's not essential to understand those technologies fully, for our purposes, but they are mentioned in the discussion on this page.

The most relevant question for a project like OSE is – is Scrum applicable outside the software development world? This is the answer that Joe Justice and the WikiSpeed team answer with a resounding “Yes!” In the 10-minute TEDX talk below, he explains briefly how the WikiSpeed Team, a collection of 44 volunteers in 4 countries, in three months used Scrum and associated processes to design and build a road-certifiable 4-person commuter car that can get over 100 miles per gallon in standard EPA road tests. The relevance of this to OSE is obvious – a distributed team of volunteers co-developing revolutionary hardware, sound familiar? It's well worth your while to spend a few hours absorbing the information on Scrum that this page points to, and to help explore its relevance for OSE in general, and the GVCS in particular.

In this video, Joe Justice, of WikiSpeed, explains the process his all-volunteer design team used to exceed expectations in their fuel-efficient car design.

<html><iframe width="300" height="182" src="http://www.youtube.com/watch?v=x8jdx-lf2Dw" frameborder="0" allowfullscreen></iframe></html>

.
.

.
.

==What is Scrum?==

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/watch?v=Q5k7a9YEoUI" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
The video above is a great first introduction to Scrum! It's fast paced, and the graphics easily convey the important information.

Of course, like any single Scrum coach, this one has his own take on Scrum, and in some instances it's likely that OSE Scrum will be different.

To review his core concepts:

Roles: Product Owner, Scrum Master, Team Members (developers, testers, customers)

Release Planning:
Product Backlog– Estimate for each feature wanted in product.
Release Backlog
plan 4-12 Sprints – a substantive back log to a ship-ready state
Sprint Backlog

Burndown Chart – day by day measure of the amount of work left in a Release, or Sprint

Bugs – have a separate Defect Backlog. Resolve bugs within the Sprint.

Daily Scrum – short, standing, identify bugs.

So that video is a great introduction to Scrum, but how would we actually get started?

The Scrum process starts with the Product Owner. They are responsible for creating the Product Backlog, creating the Development Team, and for providing the Team with the tools necessary for them to work. The Scrum Master helps the Product Owner with these tasks.

===Sprint ZERO===

To get ready for the first development Sprint, the Product Owner and the Scrum Master need to meet together, and with the Team, and do some initial preparation. The amount of time spent on Sprint Zero should be limited, and agreed upon in advance. Unfinished preparation can be added to the Product Backlog when Sprint Zero is finished. Additionally, the task of adding to the Product Backlog, and refining features that are down the road a bit, will be ongoing tasks for the Product Owner.

The most important outcome of Sprint Zero is to create understanding about the value of the work. Given that OSE might choose to have a team (Scrum) of Product Owners, it could make implementation more clear if the business values we are creating are explicitly ranked. Usually the process of identifying and clarifying the business value is held more distantly from the Team. In the case of OSE, it seems likely that a group of people will be determining the relative priorities of our business values, and the relative rankings of the features that we're planning on creating.

We've been talking about ranking the features that make up the Product Backlog. In Scrum, these features are called Stories. There is an art to defining a Scrum Story, as you might imagine. Stories often take this form:

As _[User]_____, I want _[feature]_______, so that __[value]______.

An example:

* As a fabricator making a CNC Torch Table, I want complete and accurate CAD drawings, so that my efforts will result in a well-functioning machine.

Because the User is included in defining the feature, these are known as User Stories. The following video explains a good way to evaluate and improve User Stories, which are the list of features that make up the Product Backlog.

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=L_NyCczp0Fk&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.

To review the key ideas of the video:

'''Independent''' – dependencies among or between Stories need to be identified, eliminated, or tracked. An example of dependency: the training video for making a machine cannot be made until the machine is designed.
'''Negotiable''' – the Product Owner and the Team co-create the value and attributes of features (Stories)
'''Valuable''' – all Stories are connected directly to business value.
'''Estimable''' – the Team estimates the size of the Stories relative to each other.
'''Small''' – an important concept is raised here. Stories that are coming up in priority in the first or second Release should be small enough to be finished in one Sprint. Stories that are being implemented later can be large (Epics – more on this below).
'''Testable''' – knowing how we will know the Story is done, also called knowing the Definition of Done.

This review of the qualities of a good User Story gives some idea of the work to be done during Sprint Zero, while the User Stories are created, combined in one list, and then prioritized to make up the Product Backlog.

During Sprint Zero, the Product Owner will create a list of Epics. Epics are very large Stories. An example:
* As OSE, I want complete training materials in English for the 50 tools in GVCS on DVD, so that anyone with moderate experience in fabrication, and with access to the necessary tools and materials, can fabricate any of the 50 tools.

The list of Epics doesn't have to be exhaustive, but it should be thoroughly discussed and described, using the criteria for Stories developed in the video above.

Here are some further questions to be taken up during Sprint Zero:
* Do we have the right people with the right skills? Is there a need for consultants, etc.?

* Given the Epics, the values, and the definitions of done, what sort of work place, tools and technology set up are indicated?

* What is the general approach we are taking? What will be the length of our Sprints? What is the Road Map -- the key release points? How many teams will there be? If there are multiple teams, how will the Scrum Masters and the Product Owners from the multiple teams work together?

At the end of Sprint Zero, the Product Backlog must contain enough prioritized Stories to fill at least the first Release. Ideally, there would be enough Stories for two or three releases, so that the broad outlines of the technology and personnel needed can be understood.

===Definition of Done===

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=9FnZsaRujpw&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
NOTE -- this video is LOUD!

Definition of Done:
In the video, he refers to "blockers" which are impediments. There is quite a bit of excess jargon in this video, but have patience, and relate it to GVCS. For example, we not only need to have the machine design "done," but also CAD drawings, an instructional video, and many other instructional components. Unifying the release and "done-ness" of all of these is what seems like the best, and most radical!, contribution Scrum can make to GVCS. These underlying points are crucial for us to understand what is needed in Iteration Zero. See discussion of a trial run-through by Simon and Mia below for more on this.

As the first Release progresses, the Product Owner and the Scrum Master will continue to develop the Product Backlog in preparation for the next Release. By the start of the second Release, there will need to be enough prioritized Stories (including Impediment Resolutions and Technology Spikes) for that Release.

Here's a possible outline for Sprint Zero:
Describe final product
Create a team(s) workspace(s)
Determine the length of sprints
Identify business value (the criteria to measure the value of work as it's done)
Create epics. Prioritize epics (consider relative business value)
For the highest priority epic, turn the epic into stories
Prioritize the stories (consider relative business value)
For each story, create a definition of done

Describing final product

The vision of the final outcome will continually change, and this adaptability is what Scrum is designed for. To minimize too much front-loading of visioning work, focus your vision on the next product version, and envision a product with minimum functionality that addresses a narrow set of customer needs. Quickly release a first product increment, or demo it to customers and users to validate the vision. Listen to the responses to see if you are shooting for the right goal. Then adapt.

Selectively describes the product at a coarse-grained level, capturing the product’s essence. Answer the following questions:
• Who are the product's target users?
• Which needs will the product address? What value does the product add?
• Which product attributes are critical for meeting the needs selected and therefore for the success of the product? What will the product roughly look like and do? In which areas is the product going to excel?
• What are the sources of revenue and what is the business model?

To what extent should a few of these processes be pulled into the normal Sprints?

==OSE [[GVCS]] Scrum==

First, we list the projects, in order of priority. See GVCS graphic on the right. Changes are: remove pyrolysis oil and [[Babington burner]] with biomass [[Pelletizer]] for fueling modern [[Steam Engine]]s. The burner is already present in the form of the [[:File:Gasifiericon.jpg|Gasifier Icon]]
[[Image:Slide1Linz7.jpg|thumb|40 [[GVCS]] technologies.]]
#CEB press - [[Full Product Release]] achieved.
#LifeTrac - on Prototype II
#Soil Pulverizer -

==See Also==

* [http://www.scrumhw.org/ Scrum for Hardware Product Development] ''Bringing Scrum to the Hardware Product Development Community''
* [http://maccherone.com/larry/2010/02/23/top-10-questions-when-using-agile-on-hardware-projects/ Top 10 questions when using Agile on hardware projects]

[[Category:Project Management]]

Scrum

2012-03-05T02:34:28Z

Mia Van Meter: /* Sprint ZERO */

Definition: '''[[wikipedia:Scrum (development)|Scrum]]''' is an iterative and incremental methodology for software projects and product- or application-development. It is also one of the variants of [[wikipedia:agile software development|agile software development]] methodologies.

==Why would a development team use Scrum?==

As demonstrated by high-powered software teams around the world, the Scrum process can increase a development team's efficiency dramatically. In recent years, some Scrum coaches (Scrum Masters) can consistently get development teams to be six times more efficient, and it is becoming almost unremarkable for a Scrum Master to kick a team into a productive state 15 times more productive than in their pre-Scrum days.

The adoption of Scrum by Western development teams is part of a grand mimicking of Japanese manufacturing techniques, which has been going on, with patterns of waxing and waning, for many decades. Software development has become a big enough industry that its leading edge is penetrating many other industries. Its leading edge is the family of development management processes called Agile, one of which, the most popular, is Scrum.

Scrum is essentially a double handful of rules for how a team should work together, and how they should be managed. Underneath those rules is a profound understanding of human nature. What motivates us? That is the essential question which Scrum answers. Scrum rules are designed to instill ownership, motivation, and creative problem-solving in team members. The dramatic results of a well-functioning Scrum team come from the synchronistic multiplying effect of a group of developers working “in the flow.” [http://en.wikipedia.org/wiki/Jeff_Sutherland/ Jeff Sutherland], one of the creators of Scrum, refers to these as “activated” teams.

Following [http://en.wikipedia.org/wiki/Lean_software_development/ Lean] development principles, the rules of Scrum are stripped down to the essentials. One of the implications of this is that teams must adopt all the Scrum rules in order to get Scrum results. Jeff Sutherland's favorite lecture topic seems to be “Scrumbutt.” This occurs when teams say, “Yes, we're doing Scrum, but...” and explain an aspect of Scrum they decided not to implement. According to Sutherland, you cannot get dramatic results unless you are pretty much a Scrum purist. That said, Scrum can “wrap around” other software development process technologies like, for example, XP or Lean. It's not essential to understand those technologies fully, for our purposes, but they are mentioned in the discussion on this page.

The most relevant question for a project like OSE is – is Scrum applicable outside the software development world? This is the answer that Joe Justice and the WikiSpeed team answer with a resounding “Yes!” In the 10-minute TEDX talk below, he explains briefly how the WikiSpeed Team, a collection of 44 volunteers in 4 countries, in three months used Scrum and associated processes to design and build a road-certifiable 4-person commuter car that can get over 100 miles per gallon in standard EPA road tests. The relevance of this to OSE is obvious – a distributed team of volunteers co-developing revolutionary hardware, sound familiar? It's well worth your while to spend a few hours absorbing the information on Scrum that this page points to, and to help explore its relevance for OSE in general, and the GVCS in particular.

In this video, Joe Justice, of WikiSpeed, explains the process his all-volunteer design team used to exceed expectations in their fuel-efficient car design.

<html><iframe width="300" height="182" src="http://www.youtube.com/watch?v=x8jdx-lf2Dw" frameborder="0" allowfullscreen></iframe></html>

.
.

.
.

==What is Scrum?==

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/watch?v=Q5k7a9YEoUI" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
The video above is a great first introduction to Scrum! It's fast paced, and the graphics easily convey the important information.

Of course, like any single Scrum coach, this one has his own take on Scrum, and in some instances it's likely that OSE Scrum will be different.

To review his core concepts:

Roles: Product Owner, Scrum Master, Team Members (developers, testers, customers)

Release Planning:
Product Backlog– Estimate for each feature wanted in product.
Release Backlog
plan 4-12 Sprints – a substantive back log to a ship-ready state
Sprint Backlog

Burndown Chart – day by day measure of the amount of work left in a Release, or Sprint

Bugs – have a separate Defect Backlog. Resolve bugs within the Sprint.

Daily Scrum – short, standing, identify bugs.

So that video is a great introduction to Scrum, but how would we actually get started?

The Scrum process starts with the Product Owner. They are responsible for creating the Product Backlog, creating the Development Team, and for providing the Team with the tools necessary for them to work. The Scrum Master helps the Product Owner with these tasks.

===Sprint ZERO===

To get ready for the first development Sprint, the Product Owner and the Scrum Master need to meet together, and with the Team, and do some initial preparation. The amount of time spent on Sprint Zero should be limited, and agreed upon in advance. Unfinished preparation can be added to the Product Backlog when Sprint Zero is finished. Additionally, the task of adding to the Product Backlog, and refining features that are down the road a bit, will be ongoing tasks for the Product Owner.

The most important outcome of Sprint Zero is to create understanding about the value of the work. Given that OSE might choose to have a team (Scrum) of Product Owners, it could make implementation more clear if the business values we are creating are explicitly ranked. Usually the process of identifying and clarifying the business value is held more distantly from the Team. In the case of OSE, it seems likely that a group of people will be determining the relative priorities of our business values, and the relative rankings of the features that we're planning on creating.

We've been talking about ranking the features that make up the Product Backlog. In Scrum, these features are called Stories. There is an art to defining a Scrum Story, as you might imagine. Stories often take this form:

As _[User]_____, I want _[feature]_______, so that __[value]______.

An example:

* As a fabricator making a CNC Torch Table, I want complete and accurate CAD drawings, so that my efforts will result in a well-functioning machine.

Because the User is included in defining the feature, these are known as User Stories. The following video explains a good way to evaluate and improve User Stories, which are the list of features that make up the Product Backlog.

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=L_NyCczp0Fk&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.

To review the key ideas of the video:

'''Independent''' – dependencies among or between Stories need to be identified, eliminated, or tracked. An example of dependency: the training video for making a machine cannot be made until the machine is designed.
'''Negotiable''' – the Product Owner and the Team co-create the value and attributes of features (Stories)
'''Valuable''' – all Stories are connected directly to business value.
'''Estimable''' – the Team estimates the size of the Stories relative to each other.
'''Small''' – an important concept is raised here. Stories that are coming up in priority in the first or second Release should be small enough to be finished in one Sprint. Stories that are being implemented later can be large (Epics – more on this below).
'''Testable''' – knowing how we will know the Story is done, also called knowing the Definition of Done.

This review of the qualities of a good User Story gives some idea of the work to be done during Sprint Zero, while the User Stories are created, combined in one list, and then prioritized to make up the Product Backlog.

During Sprint Zero, the Product Owner will create a list of Epics. Epics are very large Stories. An example:
* As OSE, I want complete training materials in English for the 50 tools in GVCS on DVD, so that anyone with moderate experience in fabrication, and with access to the necessary tools and materials, can fabricate any of the 50 tools.

The list of Epics doesn't have to be exhaustive, but it should be thoroughly discussed and described, using the criteria for Stories developed in the video above.

Here are some further questions to be taken up during Sprint Zero:
* Do we have the right people with the right skills? Is there a need for consultants, etc.?

* Given the Epics, the values, and the definitions of done, what sort of work place, tools and technology set up are indicated?

* What is the general approach we are taking?
** what will be the length of our Sprints?
** what is the Road Map -- the key release points?
** how many teams will there be? If there are multiple teams, how will the Scrum Masters and the Product Owners from the multiple teams work together?

At the end of Sprint Zero, the Product Backlog must contain enough prioritized Stories to fill at least the first Release. Ideally, there would be enough Stories for two or three releases, so that the broad outlines of the technology and personnel needed can be understood.

===Definition of Done===

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=9FnZsaRujpw&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
NOTE -- this video is LOUD!

Definition of Done:
In the video, he refers to "blockers" which are impediments. There is quite a bit of excess jargon in this video, but have patience, and relate it to GVCS. For example, we not only need to have the machine design "done," but also CAD drawings, an instructional video, and many other instructional components. Unifying the release and "done-ness" of all of these is what seems like the best, and most radical!, contribution Scrum can make to GVCS. These underlying points are crucial for us to understand what is needed in Iteration Zero. See discussion of a trial run-through by Simon and Mia below for more on this.

As the first Release progresses, the Product Owner and the Scrum Master will continue to develop the Product Backlog in preparation for the next Release. By the start of the second Release, there will need to be enough prioritized Stories (including Impediment Resolutions and Technology Spikes) for that Release.

Here's a possible outline for Sprint Zero:
Describe final product
Create a team(s) workspace(s)
Determine the length of sprints
Identify business value (the criteria to measure the value of work as it's done)
Create epics. Prioritize epics (consider relative business value)
For the highest priority epic, turn the epic into stories
Prioritize the stories (consider relative business value)
For each story, create a definition of done

Describing final product

The vision of the final outcome will continually change, and this adaptability is what Scrum is designed for. To minimize too much front-loading of visioning work, focus your vision on the next product version, and envision a product with minimum functionality that addresses a narrow set of customer needs. Quickly release a first product increment, or demo it to customers and users to validate the vision. Listen to the responses to see if you are shooting for the right goal. Then adapt.

Selectively describes the product at a coarse-grained level, capturing the product’s essence. Answer the following questions:
• Who are the product's target users?
• Which needs will the product address? What value does the product add?
• Which product attributes are critical for meeting the needs selected and therefore for the success of the product? What will the product roughly look like and do? In which areas is the product going to excel?
• What are the sources of revenue and what is the business model?

To what extent should a few of these processes be pulled into the normal Sprints?

==OSE [[GVCS]] Scrum==

First, we list the projects, in order of priority. See GVCS graphic on the right. Changes are: remove pyrolysis oil and [[Babington burner]] with biomass [[Pelletizer]] for fueling modern [[Steam Engine]]s. The burner is already present in the form of the [[:File:Gasifiericon.jpg|Gasifier Icon]]
[[Image:Slide1Linz7.jpg|thumb|40 [[GVCS]] technologies.]]
#CEB press - [[Full Product Release]] achieved.
#LifeTrac - on Prototype II
#Soil Pulverizer -

==See Also==

* [http://www.scrumhw.org/ Scrum for Hardware Product Development] ''Bringing Scrum to the Hardware Product Development Community''
* [http://maccherone.com/larry/2010/02/23/top-10-questions-when-using-agile-on-hardware-projects/ Top 10 questions when using Agile on hardware projects]

[[Category:Project Management]]

Scrum

2012-03-05T02:32:07Z

Mia Van Meter: /* Sprint ZERO */

Definition: '''[[wikipedia:Scrum (development)|Scrum]]''' is an iterative and incremental methodology for software projects and product- or application-development. It is also one of the variants of [[wikipedia:agile software development|agile software development]] methodologies.

==Why would a development team use Scrum?==

As demonstrated by high-powered software teams around the world, the Scrum process can increase a development team's efficiency dramatically. In recent years, some Scrum coaches (Scrum Masters) can consistently get development teams to be six times more efficient, and it is becoming almost unremarkable for a Scrum Master to kick a team into a productive state 15 times more productive than in their pre-Scrum days.

The adoption of Scrum by Western development teams is part of a grand mimicking of Japanese manufacturing techniques, which has been going on, with patterns of waxing and waning, for many decades. Software development has become a big enough industry that its leading edge is penetrating many other industries. Its leading edge is the family of development management processes called Agile, one of which, the most popular, is Scrum.

Scrum is essentially a double handful of rules for how a team should work together, and how they should be managed. Underneath those rules is a profound understanding of human nature. What motivates us? That is the essential question which Scrum answers. Scrum rules are designed to instill ownership, motivation, and creative problem-solving in team members. The dramatic results of a well-functioning Scrum team come from the synchronistic multiplying effect of a group of developers working “in the flow.” [http://en.wikipedia.org/wiki/Jeff_Sutherland/ Jeff Sutherland], one of the creators of Scrum, refers to these as “activated” teams.

Following [http://en.wikipedia.org/wiki/Lean_software_development/ Lean] development principles, the rules of Scrum are stripped down to the essentials. One of the implications of this is that teams must adopt all the Scrum rules in order to get Scrum results. Jeff Sutherland's favorite lecture topic seems to be “Scrumbutt.” This occurs when teams say, “Yes, we're doing Scrum, but...” and explain an aspect of Scrum they decided not to implement. According to Sutherland, you cannot get dramatic results unless you are pretty much a Scrum purist. That said, Scrum can “wrap around” other software development process technologies like, for example, XP or Lean. It's not essential to understand those technologies fully, for our purposes, but they are mentioned in the discussion on this page.

The most relevant question for a project like OSE is – is Scrum applicable outside the software development world? This is the answer that Joe Justice and the WikiSpeed team answer with a resounding “Yes!” In the 10-minute TEDX talk below, he explains briefly how the WikiSpeed Team, a collection of 44 volunteers in 4 countries, in three months used Scrum and associated processes to design and build a road-certifiable 4-person commuter car that can get over 100 miles per gallon in standard EPA road tests. The relevance of this to OSE is obvious – a distributed team of volunteers co-developing revolutionary hardware, sound familiar? It's well worth your while to spend a few hours absorbing the information on Scrum that this page points to, and to help explore its relevance for OSE in general, and the GVCS in particular.

In this video, Joe Justice, of WikiSpeed, explains the process his all-volunteer design team used to exceed expectations in their fuel-efficient car design.

<html><iframe width="300" height="182" src="http://www.youtube.com/watch?v=x8jdx-lf2Dw" frameborder="0" allowfullscreen></iframe></html>

.
.

.
.

==What is Scrum?==

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/watch?v=Q5k7a9YEoUI" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
The video above is a great first introduction to Scrum! It's fast paced, and the graphics easily convey the important information.

Of course, like any single Scrum coach, this one has his own take on Scrum, and in some instances it's likely that OSE Scrum will be different.

To review his core concepts:

Roles: Product Owner, Scrum Master, Team Members (developers, testers, customers)

Release Planning:
Product Backlog– Estimate for each feature wanted in product.
Release Backlog
plan 4-12 Sprints – a substantive back log to a ship-ready state
Sprint Backlog

Burndown Chart – day by day measure of the amount of work left in a Release, or Sprint

Bugs – have a separate Defect Backlog. Resolve bugs within the Sprint.

Daily Scrum – short, standing, identify bugs.

So that video is a great introduction to Scrum, but how would we actually get started?

The Scrum process starts with the Product Owner. They are responsible for creating the Product Backlog, creating the Development Team, and for providing the Team with the tools necessary for them to work. The Scrum Master helps the Product Owner with these tasks.

===Sprint ZERO===

To get ready for the first development Sprint, the Product Owner and the Scrum Master need to meet together, and with the Team, and do some initial preparation. The amount of time spent on Sprint Zero should be limited, and agreed upon in advance. Unfinished preparation can be added to the Product Backlog when Sprint Zero is finished. Additionally, the task of adding to the Product Backlog, and refining features that are down the road a bit, will be ongoing tasks for the Product Owner.

The most important outcome of Sprint Zero is to create understanding about the value of the work. Given that OSE might choose to have a team (Scrum) of Product Owners, it could make implementation more clear if the business values we are creating are explicitly ranked. Usually the process of identifying and clarifying the business value is held more distantly from the Team. In the case of OSE, it seems likely that a group of people will be determining the relative priorities of our business values, and the relative rankings of the features that we're planning on creating.

We've been talking about ranking the features that make up the Product Backlog. In Scrum, these features are called Stories. There is an art to defining a Scrum Story, as you might imagine. Stories often take this form:

As _[User]_____, I want _[feature]_______, so that __[value]______.

An example:

* As a fabricator making a CNC Torch Table, I want complete and accurate CAD drawings, so that my efforts will result in a well-functioning machine.

Because the User is included in defining the feature, these are known as User Stories. The following video explains a good way to evaluate and improve User Stories, which are the list of features that make up the Product Backlog.

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=L_NyCczp0Fk&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.

To review the key ideas of the video:

'''Independent''' – dependencies among or between Stories need to be identified, eliminated, or tracked. An example of dependency: the training video for making a machine cannot be made until the machine is designed.
'''Negotiable''' – the Product Owner and the Team co-create the value and attributes of features (Stories)
'''Valuable''' – all Stories are connected directly to business value.
'''Estimable''' – the Team estimates the size of the Stories relative to each other.
'''Small''' – an important concept is raised here. Stories that are coming up in priority in the first or second Release should be small enough to be finished in one Sprint. Stories that are being implemented later can be large (Epics – more on this below).
'''Testable''' – knowing how we will know the Story is done, also called knowing the Definition of Done.

This review of the qualities of a good User Story gives some idea of the work to be done during Sprint Zero, while the User Stories are created, combined in one list, and then prioritized to make up the Product Backlog.

During Sprint Zero, the Product Owner will create a list of Epics. Epics are very large Stories. An example:
* As OSE, I want complete training materials in English for the 50 tools in GVCS on DVD, so that anyone with moderate experience in fabrication, and with access to the necessary tools and materials, can fabricate any of the 50 tools.

The list of Epics doesn't have to be exhaustive, but it should be thoroughly discussed and described, using the criteria for Stories developed in the video above.

Here are some further questions to be taken up during Sprint Zero:
* Do we have the right people with the right skills? Is there a need for consultants, etc.?

* Given the Epics, the values, and the definitions of done, what sort of work place, tools and technology set up are indicated?

* What is the general approach we are taking?
- what will be the length of our Sprints?
- what is the Road Map -- the key release points?
- how many teams will there be? If there are multiple teams, how will the Scrum Masters and the Product Owners from the multiple teams work together?

At the end of Sprint Zero, the Product Backlog must contain enough prioritized Stories to fill at least the first Release. Ideally, there would be enough Stories for two or three releases, so that the broad outlines of the technology and personnel needed can be understood.

===Definition of Done===

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=9FnZsaRujpw&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
NOTE -- this video is LOUD!

Definition of Done:
In the video, he refers to "blockers" which are impediments. There is quite a bit of excess jargon in this video, but have patience, and relate it to GVCS. For example, we not only need to have the machine design "done," but also CAD drawings, an instructional video, and many other instructional components. Unifying the release and "done-ness" of all of these is what seems like the best, and most radical!, contribution Scrum can make to GVCS. These underlying points are crucial for us to understand what is needed in Iteration Zero. See discussion of a trial run-through by Simon and Mia below for more on this.

As the first Release progresses, the Product Owner and the Scrum Master will continue to develop the Product Backlog in preparation for the next Release. By the start of the second Release, there will need to be enough prioritized Stories (including Impediment Resolutions and Technology Spikes) for that Release.

Here's a possible outline for Sprint Zero:
Describe final product
Create a team(s) workspace(s)
Determine the length of sprints
Identify business value (the criteria to measure the value of work as it's done)
Create epics. Prioritize epics (consider relative business value)
For the highest priority epic, turn the epic into stories
Prioritize the stories (consider relative business value)
For each story, create a definition of done

Describing final product

The vision of the final outcome will continually change, and this adaptability is what Scrum is designed for. To minimize too much front-loading of visioning work, focus your vision on the next product version, and envision a product with minimum functionality that addresses a narrow set of customer needs. Quickly release a first product increment, or demo it to customers and users to validate the vision. Listen to the responses to see if you are shooting for the right goal. Then adapt.

Selectively describes the product at a coarse-grained level, capturing the product’s essence. Answer the following questions:
• Who are the product's target users?
• Which needs will the product address? What value does the product add?
• Which product attributes are critical for meeting the needs selected and therefore for the success of the product? What will the product roughly look like and do? In which areas is the product going to excel?
• What are the sources of revenue and what is the business model?

To what extent should a few of these processes be pulled into the normal Sprints?

==OSE [[GVCS]] Scrum==

First, we list the projects, in order of priority. See GVCS graphic on the right. Changes are: remove pyrolysis oil and [[Babington burner]] with biomass [[Pelletizer]] for fueling modern [[Steam Engine]]s. The burner is already present in the form of the [[:File:Gasifiericon.jpg|Gasifier Icon]]
[[Image:Slide1Linz7.jpg|thumb|40 [[GVCS]] technologies.]]
#CEB press - [[Full Product Release]] achieved.
#LifeTrac - on Prototype II
#Soil Pulverizer -

==See Also==

* [http://www.scrumhw.org/ Scrum for Hardware Product Development] ''Bringing Scrum to the Hardware Product Development Community''
* [http://maccherone.com/larry/2010/02/23/top-10-questions-when-using-agile-on-hardware-projects/ Top 10 questions when using Agile on hardware projects]

[[Category:Project Management]]

Scrum

2012-03-05T02:28:35Z

Mia Van Meter: /* Definition of Done */ creating a new subsection

Definition: '''[[wikipedia:Scrum (development)|Scrum]]''' is an iterative and incremental methodology for software projects and product- or application-development. It is also one of the variants of [[wikipedia:agile software development|agile software development]] methodologies.

==Why would a development team use Scrum?==

As demonstrated by high-powered software teams around the world, the Scrum process can increase a development team's efficiency dramatically. In recent years, some Scrum coaches (Scrum Masters) can consistently get development teams to be six times more efficient, and it is becoming almost unremarkable for a Scrum Master to kick a team into a productive state 15 times more productive than in their pre-Scrum days.

The adoption of Scrum by Western development teams is part of a grand mimicking of Japanese manufacturing techniques, which has been going on, with patterns of waxing and waning, for many decades. Software development has become a big enough industry that its leading edge is penetrating many other industries. Its leading edge is the family of development management processes called Agile, one of which, the most popular, is Scrum.

Scrum is essentially a double handful of rules for how a team should work together, and how they should be managed. Underneath those rules is a profound understanding of human nature. What motivates us? That is the essential question which Scrum answers. Scrum rules are designed to instill ownership, motivation, and creative problem-solving in team members. The dramatic results of a well-functioning Scrum team come from the synchronistic multiplying effect of a group of developers working “in the flow.” [http://en.wikipedia.org/wiki/Jeff_Sutherland/ Jeff Sutherland], one of the creators of Scrum, refers to these as “activated” teams.

Following [http://en.wikipedia.org/wiki/Lean_software_development/ Lean] development principles, the rules of Scrum are stripped down to the essentials. One of the implications of this is that teams must adopt all the Scrum rules in order to get Scrum results. Jeff Sutherland's favorite lecture topic seems to be “Scrumbutt.” This occurs when teams say, “Yes, we're doing Scrum, but...” and explain an aspect of Scrum they decided not to implement. According to Sutherland, you cannot get dramatic results unless you are pretty much a Scrum purist. That said, Scrum can “wrap around” other software development process technologies like, for example, XP or Lean. It's not essential to understand those technologies fully, for our purposes, but they are mentioned in the discussion on this page.

The most relevant question for a project like OSE is – is Scrum applicable outside the software development world? This is the answer that Joe Justice and the WikiSpeed team answer with a resounding “Yes!” In the 10-minute TEDX talk below, he explains briefly how the WikiSpeed Team, a collection of 44 volunteers in 4 countries, in three months used Scrum and associated processes to design and build a road-certifiable 4-person commuter car that can get over 100 miles per gallon in standard EPA road tests. The relevance of this to OSE is obvious – a distributed team of volunteers co-developing revolutionary hardware, sound familiar? It's well worth your while to spend a few hours absorbing the information on Scrum that this page points to, and to help explore its relevance for OSE in general, and the GVCS in particular.

In this video, Joe Justice, of WikiSpeed, explains the process his all-volunteer design team used to exceed expectations in their fuel-efficient car design.

<html><iframe width="300" height="182" src="http://www.youtube.com/watch?v=x8jdx-lf2Dw" frameborder="0" allowfullscreen></iframe></html>

.
.

.
.

==What is Scrum?==

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/watch?v=Q5k7a9YEoUI" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
The video above is a great first introduction to Scrum! It's fast paced, and the graphics easily convey the important information.

Of course, like any single Scrum coach, this one has his own take on Scrum, and in some instances it's likely that OSE Scrum will be different.

To review his core concepts:

Roles: Product Owner, Scrum Master, Team Members (developers, testers, customers)

Release Planning:
Product Backlog– Estimate for each feature wanted in product.
Release Backlog
plan 4-12 Sprints – a substantive back log to a ship-ready state
Sprint Backlog

Burndown Chart – day by day measure of the amount of work left in a Release, or Sprint

Bugs – have a separate Defect Backlog. Resolve bugs within the Sprint.

Daily Scrum – short, standing, identify bugs.

So that video is a great introduction to Scrum, but how would we actually get started?

The Scrum process starts with the Product Owner. They are responsible for creating the Product Backlog, creating the Development Team, and for providing the Team with the tools necessary for them to work. The Scrum Master helps the Product Owner with these tasks.

===Sprint ZERO===

To get ready for the first development Sprint, the Product Owner and the Scrum Master need to meet together, and with the Team, and do some initial preparation. The amount of time spent on Sprint Zero should be limited, and agreed upon in advance. Unfinished preparation can be added to the Product Backlog when Sprint Zero is finished. Additionally, the task of adding to the Product Backlog, and refining features that are down the road a bit, will be ongoing tasks for the Product Owner.

The most important outcome of Sprint Zero is to create understanding about the value of the work. Given that OSE might choose to have a team (Scrum) of Product Owners, it could make implementation more clear if the business values we are creating are explicitly ranked. Usually the process of identifying and clarifying the business value is held more distantly from the Team. In the case of OSE, it seems likely that a group of people will be determining the relative priorities of our business values, and the relative rankings of the features that we're planning on creating.

We've been talking about ranking the features that make up the Product Backlog. In Scrum, these features are called Stories. There is an art to defining a Scrum Story, as you might imagine. Stories often take this form:

As _[User]_____, I want _[feature]_______, so that __[value]______.

An example:

* As a fabricator making a CNC Torch Table, I want complete and accurate CAD drawings, so that my efforts will result in a well-functioning machine.

Because the User is included in defining the feature, these are known as User Stories. The following video explains a good way to evaluate and improve User Stories, which are the list of features that make up the Product Backlog.

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=L_NyCczp0Fk&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.

To review the key ideas of the video:

'''Independent''' – dependencies among or between Stories need to be identified, eliminated, or tracked. An example of dependency: the training video for making a machine cannot be made until the machine is designed.
'''Negotiable''' – the Product Owner and the Team co-create the value and attributes of features (Stories)
'''Valuable''' – all Stories are connected directly to business value.
'''Estimable''' – the Team estimates the size of the Stories relative to each other.
'''Small''' – an important concept is raised here. Stories that are coming up in priority in the first or second Release should be small enough to be finished in one Sprint. Stories that are being implemented later can be large (Epics – more on this below).
'''Testable''' – knowing how we will know the Story is done, also called knowing the Definition of Done.

This review of the qualities of a good User Story gives some idea of the work to be done during Sprint Zero, while the User Stories are created, and combined to make up the Product Backlog.

During Sprint Zero, the Product Owner will create a list of Epics. Epics are very large Stories. An example:
* As OSE, I want complete training materials in English for the 50 tools in GVCS on DVD, so that anyone with moderate experience in fabrication, and with access to the necessary tools and materials, can fabricate any of the 50 tools.

The list of Epics doesn't have to be exhaustive, but it should be thoroughly discussed and described, using the criteria for Stories developed in the video above.

Here are some further questions to be taken up during Sprint Zero:
* Do we have the right people with the right skills? Is there a need for consultants, etc.?

* Given the Epics, the values, and the definitions of done, what sort of work place, tools and technology set up are indicated?

* What is the general approach we are taking?
- what will be the length of our Sprints?
- what is the Road Map -- the key release points?
- how many teams will there be? If there are multiple teams, how will the Scrum Masters and the Product Owners from the multiple teams work together?

At the end of Sprint Zero, the Product Backlog must contain enough prioritized Stories to fill at least the first Release. Ideally, there would be enough Stories for two or three releases, so that the broad outlines of the technology and personnel needed can be understood.

===Definition of Done===

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=9FnZsaRujpw&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
NOTE -- this video is LOUD!

Definition of Done:
In the video, he refers to "blockers" which are impediments. There is quite a bit of excess jargon in this video, but have patience, and relate it to GVCS. For example, we not only need to have the machine design "done," but also CAD drawings, an instructional video, and many other instructional components. Unifying the release and "done-ness" of all of these is what seems like the best, and most radical!, contribution Scrum can make to GVCS. These underlying points are crucial for us to understand what is needed in Iteration Zero. See discussion of a trial run-through by Simon and Mia below for more on this.

As the first Release progresses, the Product Owner and the Scrum Master will continue to develop the Product Backlog in preparation for the next Release. By the start of the second Release, there will need to be enough prioritized Stories (including Impediment Resolutions and Technology Spikes) for that Release.

Here's a possible outline for Sprint Zero:
Describe final product
Create a team(s) workspace(s)
Determine the length of sprints
Identify business value (the criteria to measure the value of work as it's done)
Create epics. Prioritize epics (consider relative business value)
For the highest priority epic, turn the epic into stories
Prioritize the stories (consider relative business value)
For each story, create a definition of done

Describing final product

The vision of the final outcome will continually change, and this adaptability is what Scrum is designed for. To minimize too much front-loading of visioning work, focus your vision on the next product version, and envision a product with minimum functionality that addresses a narrow set of customer needs. Quickly release a first product increment, or demo it to customers and users to validate the vision. Listen to the responses to see if you are shooting for the right goal. Then adapt.

Selectively describes the product at a coarse-grained level, capturing the product’s essence. Answer the following questions:
• Who are the product's target users?
• Which needs will the product address? What value does the product add?
• Which product attributes are critical for meeting the needs selected and therefore for the success of the product? What will the product roughly look like and do? In which areas is the product going to excel?
• What are the sources of revenue and what is the business model?

To what extent should a few of these processes be pulled into the normal Sprints?

==OSE [[GVCS]] Scrum==

First, we list the projects, in order of priority. See GVCS graphic on the right. Changes are: remove pyrolysis oil and [[Babington burner]] with biomass [[Pelletizer]] for fueling modern [[Steam Engine]]s. The burner is already present in the form of the [[:File:Gasifiericon.jpg|Gasifier Icon]]
[[Image:Slide1Linz7.jpg|thumb|40 [[GVCS]] technologies.]]
#CEB press - [[Full Product Release]] achieved.
#LifeTrac - on Prototype II
#Soil Pulverizer -

==See Also==

* [http://www.scrumhw.org/ Scrum for Hardware Product Development] ''Bringing Scrum to the Hardware Product Development Community''
* [http://maccherone.com/larry/2010/02/23/top-10-questions-when-using-agile-on-hardware-projects/ Top 10 questions when using Agile on hardware projects]

[[Category:Project Management]]

Scrum

2012-03-05T02:10:19Z

Mia Van Meter: /* Sprint ZERO */ introducing Story video

Definition: '''[[wikipedia:Scrum (development)|Scrum]]''' is an iterative and incremental methodology for software projects and product- or application-development. It is also one of the variants of [[wikipedia:agile software development|agile software development]] methodologies.

==Why would a development team use Scrum?==

As demonstrated by high-powered software teams around the world, the Scrum process can increase a development team's efficiency dramatically. In recent years, some Scrum coaches (Scrum Masters) can consistently get development teams to be six times more efficient, and it is becoming almost unremarkable for a Scrum Master to kick a team into a productive state 15 times more productive than in their pre-Scrum days.

The adoption of Scrum by Western development teams is part of a grand mimicking of Japanese manufacturing techniques, which has been going on, with patterns of waxing and waning, for many decades. Software development has become a big enough industry that its leading edge is penetrating many other industries. Its leading edge is the family of development management processes called Agile, one of which, the most popular, is Scrum.

Scrum is essentially a double handful of rules for how a team should work together, and how they should be managed. Underneath those rules is a profound understanding of human nature. What motivates us? That is the essential question which Scrum answers. Scrum rules are designed to instill ownership, motivation, and creative problem-solving in team members. The dramatic results of a well-functioning Scrum team come from the synchronistic multiplying effect of a group of developers working “in the flow.” [http://en.wikipedia.org/wiki/Jeff_Sutherland/ Jeff Sutherland], one of the creators of Scrum, refers to these as “activated” teams.

Following [http://en.wikipedia.org/wiki/Lean_software_development/ Lean] development principles, the rules of Scrum are stripped down to the essentials. One of the implications of this is that teams must adopt all the Scrum rules in order to get Scrum results. Jeff Sutherland's favorite lecture topic seems to be “Scrumbutt.” This occurs when teams say, “Yes, we're doing Scrum, but...” and explain an aspect of Scrum they decided not to implement. According to Sutherland, you cannot get dramatic results unless you are pretty much a Scrum purist. That said, Scrum can “wrap around” other software development process technologies like, for example, XP or Lean. It's not essential to understand those technologies fully, for our purposes, but they are mentioned in the discussion on this page.

The most relevant question for a project like OSE is – is Scrum applicable outside the software development world? This is the answer that Joe Justice and the WikiSpeed team answer with a resounding “Yes!” In the 10-minute TEDX talk below, he explains briefly how the WikiSpeed Team, a collection of 44 volunteers in 4 countries, in three months used Scrum and associated processes to design and build a road-certifiable 4-person commuter car that can get over 100 miles per gallon in standard EPA road tests. The relevance of this to OSE is obvious – a distributed team of volunteers co-developing revolutionary hardware, sound familiar? It's well worth your while to spend a few hours absorbing the information on Scrum that this page points to, and to help explore its relevance for OSE in general, and the GVCS in particular.

In this video, Joe Justice, of WikiSpeed, explains the process his all-volunteer design team used to exceed expectations in their fuel-efficient car design.

<html><iframe width="300" height="182" src="http://www.youtube.com/watch?v=x8jdx-lf2Dw" frameborder="0" allowfullscreen></iframe></html>

.
.

.
.

==What is Scrum?==

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/watch?v=Q5k7a9YEoUI" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
The video above is a great first introduction to Scrum! It's fast paced, and the graphics easily convey the important information.

Of course, like any single Scrum coach, this one has his own take on Scrum, and in some instances it's likely that OSE Scrum will be different.

To review his core concepts:

Roles: Product Owner, Scrum Master, Team Members (developers, testers, customers)

Release Planning:
Product Backlog– Estimate for each feature wanted in product.
Release Backlog
plan 4-12 Sprints – a substantive back log to a ship-ready state
Sprint Backlog

Burndown Chart – day by day measure of the amount of work left in a Release, or Sprint

Bugs – have a separate Defect Backlog. Resolve bugs within the Sprint.

Daily Scrum – short, standing, identify bugs.

So that video is a great introduction to Scrum, but how would we actually get started?

The Scrum process starts with the Product Owner. They are responsible for creating the Product Backlog, creating the Development Team, and for providing the Team with the tools necessary for them to work. The Scrum Master helps the Product Owner with these tasks.

===Sprint ZERO===

To get ready for the first development Sprint, the Product Owner and the Scrum Master need to meet together, and with the Team, and do some initial preparation. The amount of time spent on Sprint Zero should be limited, and agreed upon in advance. Unfinished preparation can be added to the Product Backlog when Sprint Zero is finished. Additionally, the task of adding to the Product Backlog, and refining features that are down the road a bit, will be ongoing tasks for the Product Owner.

The most important outcome of Sprint Zero is to create understanding about the value of the work. Given that OSE might choose to have a team (Scrum) of Product Owners, it could make implementation more clear if the business values we are creating are explicitly ranked. Usually the process of identifying and clarifying the business value is held more distantly from the Team. In the case of OSE, it seems likely that a group of people will be determining the relative priorities of our business values, and the relative rankings of the features that we're planning on creating.

We've been talking about ranking the features that make up the Product Backlog. In Scrum, these features are called Stories. There is an art to defining a Scrum Story, as you might imagine. Stories often take this form:

As ______, I want ________, so that ________.

An example:

As a fabricator making a CNC Torch Table, I want complete and accurate CAD drawings, so that my efforts will result in a well-functioning machine.

The following video explains a good way to evaluate and improve Stories, which are the list of features that make up the Product Backlog.

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=L_NyCczp0Fk&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.

During Sprint Zero, the list of Epics is given careful consideration. It doesn't have to be exhaustive, but it should be thoroughly discussed and described, using the criteria for Stories in the video above.

Another important outcome of Sprint Zero is to get SOME of the requirements, or tests that products will be subjected to, which in Scrum terms make up the 'definition of done.' In Scrum, you cannot exhaustively list all the requirements for 'done.' Part of the philosophy is that the Product Owner's needs will change throughout the entire process, so their definition of done will necessarily change as well.

Here are some further questions to be taken up during Sprint Zero:
* Do we have the right people with the right skills? Is there a need for consultants, etc.?

* Given the Epics, the values, and the definitions of done, what sort of work place, tools and technology set up is indicated?

* What is the general approach we are taking?
- what will be the length of our Sprints?
- what is the Road Map -- the key release points?
- how many teams will there be? If there are multiple teams, how will the Scrum Masters and the Product Owners from the multiple teams work together?

At the end of Sprint Zero, the Product Backlog must contain enough prioritized Stories to fill at least the first release. Ideally, there would be enough Stories for three releases, so that the broad outlines of the technology and personnel needed can be understood. At the start of all Releases, Impediments and Technology Spikes need to be prioritized within the complete list of Stories. (Technology Spikes are plans to use Team members time to create necessary Team infrastructure.)

Stories. Most people working with Scrum refer to each entry in the Product Backlog, called features in the video, as a Story. The formula for a Story is: As ______, I want ________, so that ________.

Epic backlog. This is a collection of the top level Stories OSE is creating. Epics are too large to finish in one release, and so they are not placed in the Product Backlog. Instead, the Product Owner needs to break each Epic up into Stories that can be placed on the Product Backlog. An example of an Epic:
* As OSE, I want complete training materials in English for the 50 tools in GVCS on DVD, so that anyone with moderate experience in fabrication, and with access to the necessary tools and materials, can fabricate any of the 50 tools.

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=9FnZsaRujpw&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
NOTE -- this video is LOUD!

Definition of Done:
In the video, he refers to "blockers" which are impediments. There is quite a bit of excess jargon in this video, but have patience, and relate it to GVCS. For example, we not only need to have the machine design "done," but also CAD drawings, an instructional video, and many other instructional components. Unifying the release and "done-ness" of all of these is what seems like the best, and most radical!, contribution Scrum can make to GVCS. These underlying points are crucial for us to understand what is needed in Iteration Zero. See discussion of a trial run-through by Simon and Mia below for more on this.

As the first Release progresses, the Product Owner and the Scrum Master will continue to develop the Product Backlog in preparation for the next Release. By the start of the second Release, there will need to be enough prioritized Stories (including Impediment Resolutions and Technology Spikes) for that Release.

Here's a possible outline for Sprint Zero:
Describe final product
Create a team(s) workspace(s)
Determine the length of sprints
Identify business value (the criteria to measure the value of work as it's done)
Create epics. Prioritize epics (consider relative business value)
For the highest priority epic, turn the epic into stories
Prioritize the stories (consider relative business value)
For each story, create a definition of done

Describing final product

The vision of the final outcome will continually change, and this adaptability is what Scrum is designed for. To minimize too much front-loading of visioning work, focus your vision on the next product version, and envision a product with minimum functionality that addresses a narrow set of customer needs. Quickly release a first product increment, or demo it to customers and users to validate the vision. Listen to the responses to see if you are shooting for the right goal. Then adapt.

Selectively describes the product at a coarse-grained level, capturing the product’s essence. Answer the following questions:
• Who are the product's target users?
• Which needs will the product address? What value does the product add?
• Which product attributes are critical for meeting the needs selected and therefore for the success of the product? What will the product roughly look like and do? In which areas is the product going to excel?
• What are the sources of revenue and what is the business model?

To what extent should a few of these processes be pulled into the normal Sprints?

==OSE [[GVCS]] Scrum==

First, we list the projects, in order of priority. See GVCS graphic on the right. Changes are: remove pyrolysis oil and [[Babington burner]] with biomass [[Pelletizer]] for fueling modern [[Steam Engine]]s. The burner is already present in the form of the [[:File:Gasifiericon.jpg|Gasifier Icon]]
[[Image:Slide1Linz7.jpg|thumb|40 [[GVCS]] technologies.]]
#CEB press - [[Full Product Release]] achieved.
#LifeTrac - on Prototype II
#Soil Pulverizer -

==See Also==

* [http://www.scrumhw.org/ Scrum for Hardware Product Development] ''Bringing Scrum to the Hardware Product Development Community''
* [http://maccherone.com/larry/2010/02/23/top-10-questions-when-using-agile-on-hardware-projects/ Top 10 questions when using Agile on hardware projects]

[[Category:Project Management]]

Scrum

2012-03-05T02:00:10Z

Mia Van Meter: /* Sprint ZERO */

Definition: '''[[wikipedia:Scrum (development)|Scrum]]''' is an iterative and incremental methodology for software projects and product- or application-development. It is also one of the variants of [[wikipedia:agile software development|agile software development]] methodologies.

==Why would a development team use Scrum?==

As demonstrated by high-powered software teams around the world, the Scrum process can increase a development team's efficiency dramatically. In recent years, some Scrum coaches (Scrum Masters) can consistently get development teams to be six times more efficient, and it is becoming almost unremarkable for a Scrum Master to kick a team into a productive state 15 times more productive than in their pre-Scrum days.

The adoption of Scrum by Western development teams is part of a grand mimicking of Japanese manufacturing techniques, which has been going on, with patterns of waxing and waning, for many decades. Software development has become a big enough industry that its leading edge is penetrating many other industries. Its leading edge is the family of development management processes called Agile, one of which, the most popular, is Scrum.

Scrum is essentially a double handful of rules for how a team should work together, and how they should be managed. Underneath those rules is a profound understanding of human nature. What motivates us? That is the essential question which Scrum answers. Scrum rules are designed to instill ownership, motivation, and creative problem-solving in team members. The dramatic results of a well-functioning Scrum team come from the synchronistic multiplying effect of a group of developers working “in the flow.” [http://en.wikipedia.org/wiki/Jeff_Sutherland/ Jeff Sutherland], one of the creators of Scrum, refers to these as “activated” teams.

Following [http://en.wikipedia.org/wiki/Lean_software_development/ Lean] development principles, the rules of Scrum are stripped down to the essentials. One of the implications of this is that teams must adopt all the Scrum rules in order to get Scrum results. Jeff Sutherland's favorite lecture topic seems to be “Scrumbutt.” This occurs when teams say, “Yes, we're doing Scrum, but...” and explain an aspect of Scrum they decided not to implement. According to Sutherland, you cannot get dramatic results unless you are pretty much a Scrum purist. That said, Scrum can “wrap around” other software development process technologies like, for example, XP or Lean. It's not essential to understand those technologies fully, for our purposes, but they are mentioned in the discussion on this page.

The most relevant question for a project like OSE is – is Scrum applicable outside the software development world? This is the answer that Joe Justice and the WikiSpeed team answer with a resounding “Yes!” In the 10-minute TEDX talk below, he explains briefly how the WikiSpeed Team, a collection of 44 volunteers in 4 countries, in three months used Scrum and associated processes to design and build a road-certifiable 4-person commuter car that can get over 100 miles per gallon in standard EPA road tests. The relevance of this to OSE is obvious – a distributed team of volunteers co-developing revolutionary hardware, sound familiar? It's well worth your while to spend a few hours absorbing the information on Scrum that this page points to, and to help explore its relevance for OSE in general, and the GVCS in particular.

In this video, Joe Justice, of WikiSpeed, explains the process his all-volunteer design team used to exceed expectations in their fuel-efficient car design.

<html><iframe width="300" height="182" src="http://www.youtube.com/watch?v=x8jdx-lf2Dw" frameborder="0" allowfullscreen></iframe></html>

.
.

.
.

==What is Scrum?==

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/watch?v=Q5k7a9YEoUI" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
The video above is a great first introduction to Scrum! It's fast paced, and the graphics easily convey the important information.

Of course, like any single Scrum coach, this one has his own take on Scrum, and in some instances it's likely that OSE Scrum will be different.

To review his core concepts:

Roles: Product Owner, Scrum Master, Team Members (developers, testers, customers)

Release Planning:
Product Backlog– Estimate for each feature wanted in product.
Release Backlog
plan 4-12 Sprints – a substantive back log to a ship-ready state
Sprint Backlog

Burndown Chart – day by day measure of the amount of work left in a Release, or Sprint

Bugs – have a separate Defect Backlog. Resolve bugs within the Sprint.

Daily Scrum – short, standing, identify bugs.

So that video is a great introduction to Scrum, but how would we actually get started?

The Scrum process starts with the Product Owner. They are responsible for creating the Product Backlog, creating the Development Team, and for providing the Team with the tools necessary for them to work. The Scrum Master helps the Product Owner with these tasks.

===Sprint ZERO===

To get ready for the first development Sprint, the Product Owner and the Scrum Master need to meet together, and with the Team, and do some initial preparation. The amount of time spent on Sprint Zero should be limited, and agreed upon in advance. Unfinished preparation can be added to the Product Backlog when Sprint Zero is finished. Additionally, the task of adding to the Product Backlog, and refining features that are down the road a bit, will be ongoing tasks for the Product Owner.

The most important outcome of Sprint Zero is to create understanding about the value of the work. Given that OSE might choose to have a team (Scrum) of Product Owners, it could make implementation more clear if the business values we are creating are explicitly ranked. Usually the process of identifying and clarifying the business value is held more distantly from the Team. In the case of OSE, it seems likely that a group of people will be determining the relative priorities of our business values, and the relative rankings of the features that we're planning on creating.

Before we can really talk more about creating the Product Backlog, it's important to understand the concept of a "Story." The following video explains a good way to evaluate and improve Stories, which are the list of features that make up the Product Backlog.

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=L_NyCczp0Fk&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.

During Sprint Zero, the list of Epics is given careful consideration. It doesn't have to be exhaustive, but it should be thoroughly discussed and described, using the criteria for Stories in the video above.

Another important outcome of Sprint Zero is to get SOME of the requirements, or tests that products will be subjected to, which in Scrum terms make up the 'definition of done.' In Scrum, you cannot exhaustively list all the requirements for 'done.' Part of the philosophy is that the Product Owner's needs will change throughout the entire process, so their definition of done will necessarily change as well.

Here are some further questions to be taken up during Sprint Zero:
* Do we have the right people with the right skills? Is there a need for consultants, etc.?

* Given the Epics, the values, and the definitions of done, what sort of work place, tools and technology set up is indicated?

* What is the general approach we are taking?
- what will be the length of our Sprints?
- what is the Road Map -- the key release points?
- how many teams will there be? If there are multiple teams, how will the Scrum Masters and the Product Owners from the multiple teams work together?

At the end of Sprint Zero, the Product Backlog must contain enough prioritized Stories to fill at least the first release. Ideally, there would be enough Stories for three releases, so that the broad outlines of the technology and personnel needed can be understood. At the start of all Releases, Impediments and Technology Spikes need to be prioritized within the complete list of Stories. (Technology Spikes are plans to use Team members time to create necessary Team infrastructure.)

Stories. Most people working with Scrum refer to each entry in the Product Backlog, called features in the video, as a Story. The formula for a Story is: As ______, I want ________, so that ________.

Epic backlog. This is a collection of the top level Stories OSE is creating. Epics are too large to finish in one release, and so they are not placed in the Product Backlog. Instead, the Product Owner needs to break each Epic up into Stories that can be placed on the Product Backlog. An example of an Epic:
* As OSE, I want complete training materials in English for the 50 tools in GVCS on DVD, so that anyone with moderate experience in fabrication, and with access to the necessary tools and materials, can fabricate any of the 50 tools.

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=9FnZsaRujpw&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
NOTE -- this video is LOUD!

Definition of Done:
In the video, he refers to "blockers" which are impediments. There is quite a bit of excess jargon in this video, but have patience, and relate it to GVCS. For example, we not only need to have the machine design "done," but also CAD drawings, an instructional video, and many other instructional components. Unifying the release and "done-ness" of all of these is what seems like the best, and most radical!, contribution Scrum can make to GVCS. These underlying points are crucial for us to understand what is needed in Iteration Zero. See discussion of a trial run-through by Simon and Mia below for more on this.

As the first Release progresses, the Product Owner and the Scrum Master will continue to develop the Product Backlog in preparation for the next Release. By the start of the second Release, there will need to be enough prioritized Stories (including Impediment Resolutions and Technology Spikes) for that Release.

Here's a possible outline for Sprint Zero:
Describe final product
Create a team(s) workspace(s)
Determine the length of sprints
Identify business value (the criteria to measure the value of work as it's done)
Create epics. Prioritize epics (consider relative business value)
For the highest priority epic, turn the epic into stories
Prioritize the stories (consider relative business value)
For each story, create a definition of done

Describing final product

The vision of the final outcome will continually change, and this adaptability is what Scrum is designed for. To minimize too much front-loading of visioning work, focus your vision on the next product version, and envision a product with minimum functionality that addresses a narrow set of customer needs. Quickly release a first product increment, or demo it to customers and users to validate the vision. Listen to the responses to see if you are shooting for the right goal. Then adapt.

Selectively describes the product at a coarse-grained level, capturing the product’s essence. Answer the following questions:
• Who are the product's target users?
• Which needs will the product address? What value does the product add?
• Which product attributes are critical for meeting the needs selected and therefore for the success of the product? What will the product roughly look like and do? In which areas is the product going to excel?
• What are the sources of revenue and what is the business model?

To what extent should a few of these processes be pulled into the normal Sprints?

==OSE [[GVCS]] Scrum==

First, we list the projects, in order of priority. See GVCS graphic on the right. Changes are: remove pyrolysis oil and [[Babington burner]] with biomass [[Pelletizer]] for fueling modern [[Steam Engine]]s. The burner is already present in the form of the [[:File:Gasifiericon.jpg|Gasifier Icon]]
[[Image:Slide1Linz7.jpg|thumb|40 [[GVCS]] technologies.]]
#CEB press - [[Full Product Release]] achieved.
#LifeTrac - on Prototype II
#Soil Pulverizer -

==See Also==

* [http://www.scrumhw.org/ Scrum for Hardware Product Development] ''Bringing Scrum to the Hardware Product Development Community''
* [http://maccherone.com/larry/2010/02/23/top-10-questions-when-using-agile-on-hardware-projects/ Top 10 questions when using Agile on hardware projects]

[[Category:Project Management]]

Scrum

2012-03-05T01:58:01Z

Mia Van Meter: /* Sprint ZERO */

Definition: '''[[wikipedia:Scrum (development)|Scrum]]''' is an iterative and incremental methodology for software projects and product- or application-development. It is also one of the variants of [[wikipedia:agile software development|agile software development]] methodologies.

==Why would a development team use Scrum?==

As demonstrated by high-powered software teams around the world, the Scrum process can increase a development team's efficiency dramatically. In recent years, some Scrum coaches (Scrum Masters) can consistently get development teams to be six times more efficient, and it is becoming almost unremarkable for a Scrum Master to kick a team into a productive state 15 times more productive than in their pre-Scrum days.

The adoption of Scrum by Western development teams is part of a grand mimicking of Japanese manufacturing techniques, which has been going on, with patterns of waxing and waning, for many decades. Software development has become a big enough industry that its leading edge is penetrating many other industries. Its leading edge is the family of development management processes called Agile, one of which, the most popular, is Scrum.

Scrum is essentially a double handful of rules for how a team should work together, and how they should be managed. Underneath those rules is a profound understanding of human nature. What motivates us? That is the essential question which Scrum answers. Scrum rules are designed to instill ownership, motivation, and creative problem-solving in team members. The dramatic results of a well-functioning Scrum team come from the synchronistic multiplying effect of a group of developers working “in the flow.” [http://en.wikipedia.org/wiki/Jeff_Sutherland/ Jeff Sutherland], one of the creators of Scrum, refers to these as “activated” teams.

Following [http://en.wikipedia.org/wiki/Lean_software_development/ Lean] development principles, the rules of Scrum are stripped down to the essentials. One of the implications of this is that teams must adopt all the Scrum rules in order to get Scrum results. Jeff Sutherland's favorite lecture topic seems to be “Scrumbutt.” This occurs when teams say, “Yes, we're doing Scrum, but...” and explain an aspect of Scrum they decided not to implement. According to Sutherland, you cannot get dramatic results unless you are pretty much a Scrum purist. That said, Scrum can “wrap around” other software development process technologies like, for example, XP or Lean. It's not essential to understand those technologies fully, for our purposes, but they are mentioned in the discussion on this page.

The most relevant question for a project like OSE is – is Scrum applicable outside the software development world? This is the answer that Joe Justice and the WikiSpeed team answer with a resounding “Yes!” In the 10-minute TEDX talk below, he explains briefly how the WikiSpeed Team, a collection of 44 volunteers in 4 countries, in three months used Scrum and associated processes to design and build a road-certifiable 4-person commuter car that can get over 100 miles per gallon in standard EPA road tests. The relevance of this to OSE is obvious – a distributed team of volunteers co-developing revolutionary hardware, sound familiar? It's well worth your while to spend a few hours absorbing the information on Scrum that this page points to, and to help explore its relevance for OSE in general, and the GVCS in particular.

In this video, Joe Justice, of WikiSpeed, explains the process his all-volunteer design team used to exceed expectations in their fuel-efficient car design.

<html><iframe width="300" height="182" src="http://www.youtube.com/watch?v=x8jdx-lf2Dw" frameborder="0" allowfullscreen></iframe></html>

.
.

.
.

==What is Scrum?==

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/watch?v=Q5k7a9YEoUI" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
The video above is a great first introduction to Scrum! It's fast paced, and the graphics easily convey the important information.

Of course, like any single Scrum coach, this one has his own take on Scrum, and in some instances it's likely that OSE Scrum will be different.

To review his core concepts:

Roles: Product Owner, Scrum Master, Team Members (developers, testers, customers)

Release Planning:
Product Backlog– Estimate for each feature wanted in product.
Release Backlog
plan 4-12 Sprints – a substantive back log to a ship-ready state
Sprint Backlog

Burndown Chart – day by day measure of the amount of work left in a Release, or Sprint

Bugs – have a separate Defect Backlog. Resolve bugs within the Sprint.

Daily Scrum – short, standing, identify bugs.

So that video is a great introduction to Scrum, but how would we actually get started?

The Scrum process starts with the Product Owner. They are responsible for creating the Product Backlog, creating the Development Team, and for providing the Team with the tools necessary for them to work. The Scrum Master helps the Product Owner with these tasks.

===Sprint ZERO===

To get ready for the first development Sprint, the Product Owner and the Scrum Master need to meet together, and with the team, and do some initial preparation. The amount of time spent on Sprint Zero should be limited, and agreed upon in advance. Unfinished preparation can be added to the Product Backlog when Sprint Zero is finished. Additionally, the task of adding to the Product Backlog, and refining features that are down the road a bit, will be ongoing tasks for the Product Owner.

The most important outcome of Sprint Zero is to create understanding about the value of the work. Given that OSE might choose to have a team (Scrum) of Product Owners, it could make implementation more clear if the business values we are creating are ranked. Usually the process of identifying and clarifying the business value is held more distantly from the Team. In the case of OSE, it seems likely that a group of people will be determining the relative priorities of our business values, and the relative rankings of the features that we're planning on creating.

Before we can really talk more about creating the Product Backlog, it's important to understand the concept of a "Story." This video explains a good way to evaluate and improve Stories, which are the list of features that make up the Product Backlog.

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=L_NyCczp0Fk&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.

During Sprint Zero, the list of Epics is given careful consideration. It doesn't have to be exhaustive, but it should be thoroughly discussed and described, using the criteria for Stories in the video above.

Another important outcome of Sprint Zero is to get SOME of the requirements, or tests that products will be subjected to, which in Scrum terms make up the 'definition of done.' In Scrum, you cannot exhaustively list all the requirements for 'done.' Part of the philosophy is that the Product Owner's needs will change throughout the entire process, so their definition of done will necessarily change as well.

Here are some further questions to be taken up during Sprint Zero:
* Do we have the right people with the right skills? Is there a need for consultants, etc.?

* Given the Epics, the values, and the definitions of done, what sort of work place, tools and technology set up is indicated?

* What is the general approach we are taking?
- what will be the length of our Sprints?
- what is the Road Map -- the key release points?
- how many teams will there be? If there are multiple teams, how will the Scrum Masters and the Product Owners from the multiple teams work together?

At the end of Sprint Zero, the Product Backlog must contain enough prioritized Stories to fill at least the first release. Ideally, there would be enough Stories for three releases, so that the broad outlines of the technology and personnel needed can be understood. At the start of all Releases, Impediments and Technology Spikes need to be prioritized within the complete list of Stories. (Technology Spikes are plans to use Team members time to create necessary Team infrastructure.)

Stories. Most people working with Scrum refer to each entry in the Product Backlog, called features in the video, as a Story. The formula for a Story is: As ______, I want ________, so that ________.

Epic backlog. This is a collection of the top level Stories OSE is creating. Epics are too large to finish in one release, and so they are not placed in the Product Backlog. Instead, the Product Owner needs to break each Epic up into Stories that can be placed on the Product Backlog. An example of an Epic:
* As OSE, I want complete training materials in English for the 50 tools in GVCS on DVD, so that anyone with moderate experience in fabrication, and with access to the necessary tools and materials, can fabricate any of the 50 tools.

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=9FnZsaRujpw&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
NOTE -- this video is LOUD!

Definition of Done:
In the video, he refers to "blockers" which are impediments. There is quite a bit of excess jargon in this video, but have patience, and relate it to GVCS. For example, we not only need to have the machine design "done," but also CAD drawings, an instructional video, and many other instructional components. Unifying the release and "done-ness" of all of these is what seems like the best, and most radical!, contribution Scrum can make to GVCS. These underlying points are crucial for us to understand what is needed in Iteration Zero. See discussion of a trial run-through by Simon and Mia below for more on this.

As the first Release progresses, the Product Owner and the Scrum Master will continue to develop the Product Backlog in preparation for the next Release. By the start of the second Release, there will need to be enough prioritized Stories (including Impediment Resolutions and Technology Spikes) for that Release.

Here's a possible outline for Sprint Zero:
Describe final product
Create a team(s) workspace(s)
Determine the length of sprints
Identify business value (the criteria to measure the value of work as it's done)
Create epics. Prioritize epics (consider relative business value)
For the highest priority epic, turn the epic into stories
Prioritize the stories (consider relative business value)
For each story, create a definition of done

Describing final product

The vision of the final outcome will continually change, and this adaptability is what Scrum is designed for. To minimize too much front-loading of visioning work, focus your vision on the next product version, and envision a product with minimum functionality that addresses a narrow set of customer needs. Quickly release a first product increment, or demo it to customers and users to validate the vision. Listen to the responses to see if you are shooting for the right goal. Then adapt.

Selectively describes the product at a coarse-grained level, capturing the product’s essence. Answer the following questions:
• Who are the product's target users?
• Which needs will the product address? What value does the product add?
• Which product attributes are critical for meeting the needs selected and therefore for the success of the product? What will the product roughly look like and do? In which areas is the product going to excel?
• What are the sources of revenue and what is the business model?

To what extent should a few of these processes be pulled into the normal Sprints?

==OSE [[GVCS]] Scrum==

First, we list the projects, in order of priority. See GVCS graphic on the right. Changes are: remove pyrolysis oil and [[Babington burner]] with biomass [[Pelletizer]] for fueling modern [[Steam Engine]]s. The burner is already present in the form of the [[:File:Gasifiericon.jpg|Gasifier Icon]]
[[Image:Slide1Linz7.jpg|thumb|40 [[GVCS]] technologies.]]
#CEB press - [[Full Product Release]] achieved.
#LifeTrac - on Prototype II
#Soil Pulverizer -

==See Also==

* [http://www.scrumhw.org/ Scrum for Hardware Product Development] ''Bringing Scrum to the Hardware Product Development Community''
* [http://maccherone.com/larry/2010/02/23/top-10-questions-when-using-agile-on-hardware-projects/ Top 10 questions when using Agile on hardware projects]

[[Category:Project Management]]

Scrum

2012-03-05T01:56:48Z

Mia Van Meter: /* What is Scrum? */ changing the order topics are introduced

Definition: '''[[wikipedia:Scrum (development)|Scrum]]''' is an iterative and incremental methodology for software projects and product- or application-development. It is also one of the variants of [[wikipedia:agile software development|agile software development]] methodologies.

==Why would a development team use Scrum?==

As demonstrated by high-powered software teams around the world, the Scrum process can increase a development team's efficiency dramatically. In recent years, some Scrum coaches (Scrum Masters) can consistently get development teams to be six times more efficient, and it is becoming almost unremarkable for a Scrum Master to kick a team into a productive state 15 times more productive than in their pre-Scrum days.

The adoption of Scrum by Western development teams is part of a grand mimicking of Japanese manufacturing techniques, which has been going on, with patterns of waxing and waning, for many decades. Software development has become a big enough industry that its leading edge is penetrating many other industries. Its leading edge is the family of development management processes called Agile, one of which, the most popular, is Scrum.

Scrum is essentially a double handful of rules for how a team should work together, and how they should be managed. Underneath those rules is a profound understanding of human nature. What motivates us? That is the essential question which Scrum answers. Scrum rules are designed to instill ownership, motivation, and creative problem-solving in team members. The dramatic results of a well-functioning Scrum team come from the synchronistic multiplying effect of a group of developers working “in the flow.” [http://en.wikipedia.org/wiki/Jeff_Sutherland/ Jeff Sutherland], one of the creators of Scrum, refers to these as “activated” teams.

Following [http://en.wikipedia.org/wiki/Lean_software_development/ Lean] development principles, the rules of Scrum are stripped down to the essentials. One of the implications of this is that teams must adopt all the Scrum rules in order to get Scrum results. Jeff Sutherland's favorite lecture topic seems to be “Scrumbutt.” This occurs when teams say, “Yes, we're doing Scrum, but...” and explain an aspect of Scrum they decided not to implement. According to Sutherland, you cannot get dramatic results unless you are pretty much a Scrum purist. That said, Scrum can “wrap around” other software development process technologies like, for example, XP or Lean. It's not essential to understand those technologies fully, for our purposes, but they are mentioned in the discussion on this page.

The most relevant question for a project like OSE is – is Scrum applicable outside the software development world? This is the answer that Joe Justice and the WikiSpeed team answer with a resounding “Yes!” In the 10-minute TEDX talk below, he explains briefly how the WikiSpeed Team, a collection of 44 volunteers in 4 countries, in three months used Scrum and associated processes to design and build a road-certifiable 4-person commuter car that can get over 100 miles per gallon in standard EPA road tests. The relevance of this to OSE is obvious – a distributed team of volunteers co-developing revolutionary hardware, sound familiar? It's well worth your while to spend a few hours absorbing the information on Scrum that this page points to, and to help explore its relevance for OSE in general, and the GVCS in particular.

In this video, Joe Justice, of WikiSpeed, explains the process his all-volunteer design team used to exceed expectations in their fuel-efficient car design.

<html><iframe width="300" height="182" src="http://www.youtube.com/watch?v=x8jdx-lf2Dw" frameborder="0" allowfullscreen></iframe></html>

.
.

.
.

==What is Scrum?==

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/watch?v=Q5k7a9YEoUI" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
The video above is a great first introduction to Scrum! It's fast paced, and the graphics easily convey the important information.

Of course, like any single Scrum coach, this one has his own take on Scrum, and in some instances it's likely that OSE Scrum will be different.

To review his core concepts:

Roles: Product Owner, Scrum Master, Team Members (developers, testers, customers)

Release Planning:
Product Backlog– Estimate for each feature wanted in product.
Release Backlog
plan 4-12 Sprints – a substantive back log to a ship-ready state
Sprint Backlog

Burndown Chart – day by day measure of the amount of work left in a Release, or Sprint

Bugs – have a separate Defect Backlog. Resolve bugs within the Sprint.

Daily Scrum – short, standing, identify bugs.

So that video is a great introduction to Scrum, but how would we actually get started?

The Scrum process starts with the Product Owner. They are responsible for creating the Product Backlog, creating the Development Team, and for providing the Team with the tools necessary for them to work. The Scrum Master helps the Product Owner with these tasks.

=Sprint ZERO=

To get ready for the first development Sprint, the Product Owner and the Scrum Master need to meet together, and with the team, and do some initial preparation. The amount of time spent on Sprint Zero should be limited, and agreed upon in advance. Unfinished preparation can be added to the Product Backlog when Sprint Zero is finished. Additionally, the task of adding to the Product Backlog, and refining features that are down the road a bit, will be ongoing tasks for the Product Owner.

The most important outcome of Sprint Zero is to create understanding about the value of the work. Given that OSE might choose to have a team (Scrum) of Product Owners, it could make implementation more clear if the business values we are creating are ranked. Usually the process of identifying and clarifying the business value is held more distantly from the Team. In the case of OSE, it seems likely that a group of people will be determining the relative priorities of our business values, and the relative rankings of the features that we're planning on creating.

Before we can really talk more about creating the Product Backlog, it's important to understand the concept of a "Story." This video explains a good way to evaluate and improve Stories, which are the list of features that make up the Product Backlog.

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=L_NyCczp0Fk&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.

During Sprint Zero, the list of Epics is given careful consideration. It doesn't have to be exhaustive, but it should be thoroughly discussed and described, using the criteria for Stories in the video above.

Another important outcome of Sprint Zero is to get SOME of the requirements, or tests that products will be subjected to, which in Scrum terms make up the 'definition of done.' In Scrum, you cannot exhaustively list all the requirements for 'done.' Part of the philosophy is that the Product Owner's needs will change throughout the entire process, so their definition of done will necessarily change as well.

Here are some further questions to be taken up during Sprint Zero:
* Do we have the right people with the right skills? Is there a need for consultants, etc.?

* Given the Epics, the values, and the definitions of done, what sort of work place, tools and technology set up is indicated?

* What is the general approach we are taking?
- what will be the length of our Sprints?
- what is the Road Map -- the key release points?
- how many teams will there be? If there are multiple teams, how will the Scrum Masters and the Product Owners from the multiple teams work together?

At the end of Sprint Zero, the Product Backlog must contain enough prioritized Stories to fill at least the first release. Ideally, there would be enough Stories for three releases, so that the broad outlines of the technology and personnel needed can be understood. At the start of all Releases, Impediments and Technology Spikes need to be prioritized within the complete list of Stories. (Technology Spikes are plans to use Team members time to create necessary Team infrastructure.)

Stories. Most people working with Scrum refer to each entry in the Product Backlog, called features in the video, as a Story. The formula for a Story is: As ______, I want ________, so that ________.

Epic backlog. This is a collection of the top level Stories OSE is creating. Epics are too large to finish in one release, and so they are not placed in the Product Backlog. Instead, the Product Owner needs to break each Epic up into Stories that can be placed on the Product Backlog. An example of an Epic:
* As OSE, I want complete training materials in English for the 50 tools in GVCS on DVD, so that anyone with moderate experience in fabrication, and with access to the necessary tools and materials, can fabricate any of the 50 tools.

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=9FnZsaRujpw&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
NOTE -- this video is LOUD!

Definition of Done:
In the video, he refers to "blockers" which are impediments. There is quite a bit of excess jargon in this video, but have patience, and relate it to GVCS. For example, we not only need to have the machine design "done," but also CAD drawings, an instructional video, and many other instructional components. Unifying the release and "done-ness" of all of these is what seems like the best, and most radical!, contribution Scrum can make to GVCS. These underlying points are crucial for us to understand what is needed in Iteration Zero. See discussion of a trial run-through by Simon and Mia below for more on this.

As the first Release progresses, the Product Owner and the Scrum Master will continue to develop the Product Backlog in preparation for the next Release. By the start of the second Release, there will need to be enough prioritized Stories (including Impediment Resolutions and Technology Spikes) for that Release.

Here's a possible outline for Sprint Zero:
Describe final product
Create a team(s) workspace(s)
Determine the length of sprints
Identify business value (the criteria to measure the value of work as it's done)
Create epics. Prioritize epics (consider relative business value)
For the highest priority epic, turn the epic into stories
Prioritize the stories (consider relative business value)
For each story, create a definition of done

Describing final product

The vision of the final outcome will continually change, and this adaptability is what Scrum is designed for. To minimize too much front-loading of visioning work, focus your vision on the next product version, and envision a product with minimum functionality that addresses a narrow set of customer needs. Quickly release a first product increment, or demo it to customers and users to validate the vision. Listen to the responses to see if you are shooting for the right goal. Then adapt.

Selectively describes the product at a coarse-grained level, capturing the product’s essence. Answer the following questions:
• Who are the product's target users?
• Which needs will the product address? What value does the product add?
• Which product attributes are critical for meeting the needs selected and therefore for the success of the product? What will the product roughly look like and do? In which areas is the product going to excel?
• What are the sources of revenue and what is the business model?

To what extent should a few of these processes be pulled into the normal Sprints?

==OSE [[GVCS]] Scrum==

First, we list the projects, in order of priority. See GVCS graphic on the right. Changes are: remove pyrolysis oil and [[Babington burner]] with biomass [[Pelletizer]] for fueling modern [[Steam Engine]]s. The burner is already present in the form of the [[:File:Gasifiericon.jpg|Gasifier Icon]]
[[Image:Slide1Linz7.jpg|thumb|40 [[GVCS]] technologies.]]
#CEB press - [[Full Product Release]] achieved.
#LifeTrac - on Prototype II
#Soil Pulverizer -

==See Also==

* [http://www.scrumhw.org/ Scrum for Hardware Product Development] ''Bringing Scrum to the Hardware Product Development Community''
* [http://maccherone.com/larry/2010/02/23/top-10-questions-when-using-agile-on-hardware-projects/ Top 10 questions when using Agile on hardware projects]

[[Category:Project Management]]

Scrum

2012-03-05T01:31:33Z

Mia Van Meter: /* What is Scrum? */ remove written notes on Justice video

Definition: '''[[wikipedia:Scrum (development)|Scrum]]''' is an iterative and incremental methodology for software projects and product- or application-development. It is also one of the variants of [[wikipedia:agile software development|agile software development]] methodologies.

==Why would a development team use Scrum?==

As demonstrated by high-powered software teams around the world, the Scrum process can increase a development team's efficiency dramatically. In recent years, some Scrum coaches (Scrum Masters) can consistently get development teams to be six times more efficient, and it is becoming almost unremarkable for a Scrum Master to kick a team into a productive state 15 times more productive than in their pre-Scrum days.

The adoption of Scrum by Western development teams is part of a grand mimicking of Japanese manufacturing techniques, which has been going on, with patterns of waxing and waning, for many decades. Software development has become a big enough industry that its leading edge is penetrating many other industries. Its leading edge is the family of development management processes called Agile, one of which, the most popular, is Scrum.

Scrum is essentially a double handful of rules for how a team should work together, and how they should be managed. Underneath those rules is a profound understanding of human nature. What motivates us? That is the essential question which Scrum answers. Scrum rules are designed to instill ownership, motivation, and creative problem-solving in team members. The dramatic results of a well-functioning Scrum team come from the synchronistic multiplying effect of a group of developers working “in the flow.” [http://en.wikipedia.org/wiki/Jeff_Sutherland/ Jeff Sutherland], one of the creators of Scrum, refers to these as “activated” teams.

Following [http://en.wikipedia.org/wiki/Lean_software_development/ Lean] development principles, the rules of Scrum are stripped down to the essentials. One of the implications of this is that teams must adopt all the Scrum rules in order to get Scrum results. Jeff Sutherland's favorite lecture topic seems to be “Scrumbutt.” This occurs when teams say, “Yes, we're doing Scrum, but...” and explain an aspect of Scrum they decided not to implement. According to Sutherland, you cannot get dramatic results unless you are pretty much a Scrum purist. That said, Scrum can “wrap around” other software development process technologies like, for example, XP or Lean. It's not essential to understand those technologies fully, for our purposes, but they are mentioned in the discussion on this page.

The most relevant question for a project like OSE is – is Scrum applicable outside the software development world? This is the answer that Joe Justice and the WikiSpeed team answer with a resounding “Yes!” In the 10-minute TEDX talk below, he explains briefly how the WikiSpeed Team, a collection of 44 volunteers in 4 countries, in three months used Scrum and associated processes to design and build a road-certifiable 4-person commuter car that can get over 100 miles per gallon in standard EPA road tests. The relevance of this to OSE is obvious – a distributed team of volunteers co-developing revolutionary hardware, sound familiar? It's well worth your while to spend a few hours absorbing the information on Scrum that this page points to, and to help explore its relevance for OSE in general, and the GVCS in particular.

In this video, Joe Justice, of WikiSpeed, explains the process his all-volunteer design team used to exceed expectations in their fuel-efficient car design.

<html><iframe width="300" height="182" src="http://www.youtube.com/watch?v=x8jdx-lf2Dw" frameborder="0" allowfullscreen></iframe></html>

.
.

.
.

==What is Scrum?==

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/watch?v=Q5k7a9YEoUI" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
The video above is a great introduction to Scrum!

He covers core concepts: Backlogs, Roles, Release Planning, Burndown Chart, Daily Scrum

Backlogs:
* [[wikipedia:Scrum (development)#Product backlog|Product Backlog]]
* Release Backlog
* Sprint Backlog

Additional related ideas useful for GVCS:

Stories. Most people working with Scrum refer to each entry in the Product Backlog, called features in the video, as a Story. The formula for a Story is: As ______, I want ________, so that ________.

Epic backlog. This is a collection of the top level Stories OSE is creating. Epics are too large to finish in one release, and so they are not placed in the Product Backlog. Instead, the Product Owner needs to break each Epic up into Stories that can be placed on the Product Backlog. An example of an Epic:
* As OSE, I want complete training materials in English for the 50 tools in GVCS on DVD, so that anyone with moderate experience in fabrication, and with access to the necessary tools and materials, can fabricate any of the 50 tools.

Roles: Product Owner, Scrum Master, Team Members (developers, testers, customers)

Additional related ideas useful for GVCS:

Product Owner -- the role of the Product Owner is so key that an additional video (below) is needed to begin to understand their role.

Scrum Master -- the video mentions keeping the project progressing smoothly, and making sure that team members have the tools they need. In fact, probably the most important role of the Scrum Master is to REMOVE IMPEDIMENTS! See the discussion below on the Daily Scrum.

Release Planning: Estimate, Sprint, Assign Stories to Sprints

Additional related ideas useful for GVCS:

In addition to Estimating the Stories, the Team needs to carefully uncover any dependencies between or among Stories. Ideally, Stories could be rewritten, sliced or otherwise modified to eliminate dependencies among Stories. If not, the dependencies should be clearly indicated on the chart showing which Stories are to be done in each Iteration. It's important that dependencies are easy to see at a glance.

Following each Sprint, there will be demonstrations, a retrospective, and then the backlog for the next iteration will be estimated, and the definitions of done reviewed with the Product Owner.

To be ready for the first Iteration, there needs to be an "Iteration Zero" (see video below, and discussion of a trial run-through by Simon and Mia).

Burndown Chart

During the first several Sprints, OSE will be sorting out what it means to be doing Scrum, and how it all works. It won't be until a few Sprints after that that the rate of work will be a useful measure. So it will be bit before we have a reliable burndown chart. This concept obviously interacts with the deadline Marcin has described for GVCS.

Daily Scrum

It could be that we want volunteers to participate in a "Daily Scrum" after they've worked about 8 hours. Which, if a volunteer is giving 15 hours a week, could be just twice a week, say. This is another piece to consider as we design our own unique Scrum. (Btw, his calling Daily Scrums into question is the main part of this video that has drawn fire from other Scrum coaches.)

The structure of a Daily Scrum is just each team member answering three questions:
1) what did I do yesterday?
2) what will I do today? (make adjustments in the chart of "In Process" Stories)
3) what are the impediments to either finishing at all, or meeting the estimated time?

The Scrum Master is responsible for eliminating any impediments. However, that could mean placing a Story about the solution to the impediment in the Product Backlog. Often, the Product Owner has to contribute to eliminating impediments, and for this reason the Product Owner attends all Daily Scrums (although they don't speak during the Daily Scrum). For Team Members, seeing impediments removed is key to creating the accelerated velocity that Scrum is famous for.

More thoughts on the Product Owner
Do we want part of this role to be distributed and collaborative? Because of the nature of OSE, it is likely that a number of people would form a Product Owner Scrum, whose Product Backlog would be all the responsibilities of an individual Product Owner in a more typical Scrum. It seems very useful to have just one person being the Product Owner for any given release. However, if we move to multiple simultaneous teams, or as we cycle through Releases, the role could be rotated.

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=L_NyCczp0Fk&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.

This video explains a good way to evaluate and improve Stories, which are the list of features that make up the Product Backlog.

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=9FnZsaRujpw&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
NOTE -- this video is LOUD!

Definition of Done:
In the video, he refers to "blockers" which are impediments. There is quite a bit of excess jargon in this video, but have patience, and relate it to GVCS. For example, we not only need to have the machine design "done," but also CAD drawings, an instructional video, and many other instructional components. Unifying the release and "done-ness" of all of these is what seems like the best, and most radical!, contribution Scrum can make to GVCS. These underlying points are crucial for us to understand what is needed in Iteration Zero. See discussion of a trial run-through by Simon and Mia below for more on this.

Sprint ZERO

To get ready for the first Sprint, the Product Owner and the Scrum Master need to meet with the team and do some initial preparation. The amount of time spent on this should be "time-boxed" like a normal Sprint. For example, team members could commit a certain amount of time over the course of two weeks to do as much as possible in that time period. Unfinished preparation can be listed as a Story on the Product Backlog when Sprint Zero is finished.

The most important outcome of Sprint Zero is to create understanding about the value of the work. Given that OSE might choose to have a team (Scrum) of Product Owners, it could make implementation more clear if the business values we are creating are ranked (see run through by Simon and Mia for an exploration of this). During Sprint Zero, the list of Epics is given careful consideration. It doesn't have to be exhaustive, but it should be thoroughly discussed and described, using the criteria for Stories in the video above.

Another important outcome of Sprint Zero is to get SOME of the requirements, or tests that products will be subjected to, which in Scrum terms make up the 'definition of done.' In Scrum, you cannot exhaustively list all the requirements for 'done.' Part of the philosophy is that the Product Owner's needs will change throughout the entire process, so their definition of done will necessarily change as well.

Here are some further questions to be taken up during Sprint Zero:
* Do we have the right people with the right skills? Is there a need for consultants, etc.?

* Given the Epics, the values, and the definitions of done, what sort of work place, tools and technology set up is indicated?

* What is the general approach we are taking?
- what will be the length of our Sprints?
- what is the Road Map -- the key release points?
- how many teams will there be? If there are multiple teams, how will the Scrum Masters and the Product Owners from the multiple teams work together?

At the end of Sprint Zero, the Product Backlog must contain enough prioritized Stories to fill at least the first release. Ideally, there would be enough Stories for three releases, so that the broad outlines of the technology and personnel needed can be understood. At the start of all Releases, Impediments and Technology Spikes need to be prioritized within the complete list of Stories. (Technology Spikes are plans to use Team members time to create necessary Team infrastructure.)

As the first Release progresses, the Product Owner and the Scrum Master will continue to develop the Product Backlog in preparation for the next Release. By the start of the second Release, there will need to be enough prioritized Stories (including Impediment Resolutions and Technology Spikes) for that Release.

Here's a possible outline for Sprint Zero:
Describe final product
Create a team(s) workspace(s)
Determine the length of sprints
Identify business value (the criteria to measure the value of work as it's done)
Create epics. Prioritize epics (consider relative business value)
For the highest priority epic, turn the epic into stories
Prioritize the stories (consider relative business value)
For each story, create a definition of done

Describing final product

The vision of the final outcome will continually change, and this adaptability is what Scrum is designed for. To minimize too much front-loading of visioning work, focus your vision on the next product version, and envision a product with minimum functionality that addresses a narrow set of customer needs. Quickly release a first product increment, or demo it to customers and users to validate the vision. Listen to the responses to see if you are shooting for the right goal. Then adapt.

Selectively describes the product at a coarse-grained level, capturing the product’s essence. Answer the following questions:
• Who are the product's target users?
• Which needs will the product address? What value does the product add?
• Which product attributes are critical for meeting the needs selected and therefore for the success of the product? What will the product roughly look like and do? In which areas is the product going to excel?
• What are the sources of revenue and what is the business model?

To what extent should a few of these processes be pulled into the normal Sprints?

==OSE [[GVCS]] Scrum==

First, we list the projects, in order of priority. See GVCS graphic on the right. Changes are: remove pyrolysis oil and [[Babington burner]] with biomass [[Pelletizer]] for fueling modern [[Steam Engine]]s. The burner is already present in the form of the [[:File:Gasifiericon.jpg|Gasifier Icon]]
[[Image:Slide1Linz7.jpg|thumb|40 [[GVCS]] technologies.]]
#CEB press - [[Full Product Release]] achieved.
#LifeTrac - on Prototype II
#Soil Pulverizer -

==See Also==

* [http://www.scrumhw.org/ Scrum for Hardware Product Development] ''Bringing Scrum to the Hardware Product Development Community''
* [http://maccherone.com/larry/2010/02/23/top-10-questions-when-using-agile-on-hardware-projects/ Top 10 questions when using Agile on hardware projects]

[[Category:Project Management]]

Scrum

2012-03-05T01:30:41Z

Mia Van Meter: /* Why would a development team use Scrum? */

Definition: '''[[wikipedia:Scrum (development)|Scrum]]''' is an iterative and incremental methodology for software projects and product- or application-development. It is also one of the variants of [[wikipedia:agile software development|agile software development]] methodologies.

==Why would a development team use Scrum?==

As demonstrated by high-powered software teams around the world, the Scrum process can increase a development team's efficiency dramatically. In recent years, some Scrum coaches (Scrum Masters) can consistently get development teams to be six times more efficient, and it is becoming almost unremarkable for a Scrum Master to kick a team into a productive state 15 times more productive than in their pre-Scrum days.

The adoption of Scrum by Western development teams is part of a grand mimicking of Japanese manufacturing techniques, which has been going on, with patterns of waxing and waning, for many decades. Software development has become a big enough industry that its leading edge is penetrating many other industries. Its leading edge is the family of development management processes called Agile, one of which, the most popular, is Scrum.

Scrum is essentially a double handful of rules for how a team should work together, and how they should be managed. Underneath those rules is a profound understanding of human nature. What motivates us? That is the essential question which Scrum answers. Scrum rules are designed to instill ownership, motivation, and creative problem-solving in team members. The dramatic results of a well-functioning Scrum team come from the synchronistic multiplying effect of a group of developers working “in the flow.” [http://en.wikipedia.org/wiki/Jeff_Sutherland/ Jeff Sutherland], one of the creators of Scrum, refers to these as “activated” teams.

Following [http://en.wikipedia.org/wiki/Lean_software_development/ Lean] development principles, the rules of Scrum are stripped down to the essentials. One of the implications of this is that teams must adopt all the Scrum rules in order to get Scrum results. Jeff Sutherland's favorite lecture topic seems to be “Scrumbutt.” This occurs when teams say, “Yes, we're doing Scrum, but...” and explain an aspect of Scrum they decided not to implement. According to Sutherland, you cannot get dramatic results unless you are pretty much a Scrum purist. That said, Scrum can “wrap around” other software development process technologies like, for example, XP or Lean. It's not essential to understand those technologies fully, for our purposes, but they are mentioned in the discussion on this page.

The most relevant question for a project like OSE is – is Scrum applicable outside the software development world? This is the answer that Joe Justice and the WikiSpeed team answer with a resounding “Yes!” In the 10-minute TEDX talk below, he explains briefly how the WikiSpeed Team, a collection of 44 volunteers in 4 countries, in three months used Scrum and associated processes to design and build a road-certifiable 4-person commuter car that can get over 100 miles per gallon in standard EPA road tests. The relevance of this to OSE is obvious – a distributed team of volunteers co-developing revolutionary hardware, sound familiar? It's well worth your while to spend a few hours absorbing the information on Scrum that this page points to, and to help explore its relevance for OSE in general, and the GVCS in particular.

In this video, Joe Justice, of WikiSpeed, explains the process his all-volunteer design team used to exceed expectations in their fuel-efficient car design.

<html><iframe width="300" height="182" src="http://www.youtube.com/watch?v=x8jdx-lf2Dw" frameborder="0" allowfullscreen></iframe></html>

.
.

.
.

==What is Scrum?==

Joe Justice, who is a professional Scrum/Agile coach in his day job, drew attention to many of the key aspects of Scrum in the video above. Here are some of the features he mentioned:
* Morale is a velocity multiplier. This is the most critical Scrum rule. Scrum is based on a modern understanding from cognitive psychology of motivation and job satisfaction.
* Repeated iterations each producing a result which delivers greater value to the user immediately
* Before design starts, create tests that will be used to see if components meet the necessary standards of value. In Scrum, this is referred to as a "definition of done."
* Visualize workflow. In Scrum jargon, this refers to "visual radiators."
* Have a process coach, referred to in Scrum as a "Scrum master"
* Relentlessly gain efficiencies in your process, referred to in Scrum as identifying and removing "impediments."
* Identify the value stream map of your company, referred to in Scrum as the "business value" you are seeking.

Other techniques WikiSpeed used are not from Scrum, but from associated Agile, XP or Lean processes:
* Modular design allowing distributed teams to change components without requiring an overall design change
* Lean -- cut costs in tooling and complexity wherever possible
* XP -- work in pairs at all times

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/watch?v=Q5k7a9YEoUI" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
The video above is a great introduction to Scrum!

He covers core concepts: Backlogs, Roles, Release Planning, Burndown Chart, Daily Scrum

Backlogs:
* [[wikipedia:Scrum (development)#Product backlog|Product Backlog]]
* Release Backlog
* Sprint Backlog

Additional related ideas useful for GVCS:

Stories. Most people working with Scrum refer to each entry in the Product Backlog, called features in the video, as a Story. The formula for a Story is: As ______, I want ________, so that ________.

Epic backlog. This is a collection of the top level Stories OSE is creating. Epics are too large to finish in one release, and so they are not placed in the Product Backlog. Instead, the Product Owner needs to break each Epic up into Stories that can be placed on the Product Backlog. An example of an Epic:
* As OSE, I want complete training materials in English for the 50 tools in GVCS on DVD, so that anyone with moderate experience in fabrication, and with access to the necessary tools and materials, can fabricate any of the 50 tools.

Roles: Product Owner, Scrum Master, Team Members (developers, testers, customers)

Additional related ideas useful for GVCS:

Product Owner -- the role of the Product Owner is so key that an additional video (below) is needed to begin to understand their role.

Scrum Master -- the video mentions keeping the project progressing smoothly, and making sure that team members have the tools they need. In fact, probably the most important role of the Scrum Master is to REMOVE IMPEDIMENTS! See the discussion below on the Daily Scrum.

Release Planning: Estimate, Sprint, Assign Stories to Sprints

Additional related ideas useful for GVCS:

In addition to Estimating the Stories, the Team needs to carefully uncover any dependencies between or among Stories. Ideally, Stories could be rewritten, sliced or otherwise modified to eliminate dependencies among Stories. If not, the dependencies should be clearly indicated on the chart showing which Stories are to be done in each Iteration. It's important that dependencies are easy to see at a glance.

Following each Sprint, there will be demonstrations, a retrospective, and then the backlog for the next iteration will be estimated, and the definitions of done reviewed with the Product Owner.

To be ready for the first Iteration, there needs to be an "Iteration Zero" (see video below, and discussion of a trial run-through by Simon and Mia).

Burndown Chart

During the first several Sprints, OSE will be sorting out what it means to be doing Scrum, and how it all works. It won't be until a few Sprints after that that the rate of work will be a useful measure. So it will be bit before we have a reliable burndown chart. This concept obviously interacts with the deadline Marcin has described for GVCS.

Daily Scrum

It could be that we want volunteers to participate in a "Daily Scrum" after they've worked about 8 hours. Which, if a volunteer is giving 15 hours a week, could be just twice a week, say. This is another piece to consider as we design our own unique Scrum. (Btw, his calling Daily Scrums into question is the main part of this video that has drawn fire from other Scrum coaches.)

The structure of a Daily Scrum is just each team member answering three questions:
1) what did I do yesterday?
2) what will I do today? (make adjustments in the chart of "In Process" Stories)
3) what are the impediments to either finishing at all, or meeting the estimated time?

The Scrum Master is responsible for eliminating any impediments. However, that could mean placing a Story about the solution to the impediment in the Product Backlog. Often, the Product Owner has to contribute to eliminating impediments, and for this reason the Product Owner attends all Daily Scrums (although they don't speak during the Daily Scrum). For Team Members, seeing impediments removed is key to creating the accelerated velocity that Scrum is famous for.

More thoughts on the Product Owner
Do we want part of this role to be distributed and collaborative? Because of the nature of OSE, it is likely that a number of people would form a Product Owner Scrum, whose Product Backlog would be all the responsibilities of an individual Product Owner in a more typical Scrum. It seems very useful to have just one person being the Product Owner for any given release. However, if we move to multiple simultaneous teams, or as we cycle through Releases, the role could be rotated.

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=L_NyCczp0Fk&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.

This video explains a good way to evaluate and improve Stories, which are the list of features that make up the Product Backlog.

<html>
<object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=9FnZsaRujpw&feature=related"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/Q5k7a9YEoUI?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object>
</html>
.
.

.
.

.
.
NOTE -- this video is LOUD!

Definition of Done:
In the video, he refers to "blockers" which are impediments. There is quite a bit of excess jargon in this video, but have patience, and relate it to GVCS. For example, we not only need to have the machine design "done," but also CAD drawings, an instructional video, and many other instructional components. Unifying the release and "done-ness" of all of these is what seems like the best, and most radical!, contribution Scrum can make to GVCS. These underlying points are crucial for us to understand what is needed in Iteration Zero. See discussion of a trial run-through by Simon and Mia below for more on this.

Sprint ZERO

To get ready for the first Sprint, the Product Owner and the Scrum Master need to meet with the team and do some initial preparation. The amount of time spent on this should be "time-boxed" like a normal Sprint. For example, team members could commit a certain amount of time over the course of two weeks to do as much as possible in that time period. Unfinished preparation can be listed as a Story on the Product Backlog when Sprint Zero is finished.

The most important outcome of Sprint Zero is to create understanding about the value of the work. Given that OSE might choose to have a team (Scrum) of Product Owners, it could make implementation more clear if the business values we are creating are ranked (see run through by Simon and Mia for an exploration of this). During Sprint Zero, the list of Epics is given careful consideration. It doesn't have to be exhaustive, but it should be thoroughly discussed and described, using the criteria for Stories in the video above.

Another important outcome of Sprint Zero is to get SOME of the requirements, or tests that products will be subjected to, which in Scrum terms make up the 'definition of done.' In Scrum, you cannot exhaustively list all the requirements for 'done.' Part of the philosophy is that the Product Owner's needs will change throughout the entire process, so their definition of done will necessarily change as well.

Here are some further questions to be taken up during Sprint Zero:
* Do we have the right people with the right skills? Is there a need for consultants, etc.?

* Given the Epics, the values, and the definitions of done, what sort of work place, tools and technology set up is indicated?

* What is the general approach we are taking?
- what will be the length of our Sprints?
- what is the Road Map -- the key release points?
- how many teams will there be? If there are multiple teams, how will the Scrum Masters and the Product Owners from the multiple teams work together?

At the end of Sprint Zero, the Product Backlog must contain enough prioritized Stories to fill at least the first release. Ideally, there would be enough Stories for three releases, so that the broad outlines of the technology and personnel needed can be understood. At the start of all Releases, Impediments and Technology Spikes need to be prioritized within the complete list of Stories. (Technology Spikes are plans to use Team members time to create necessary Team infrastructure.)

As the first Release progresses, the Product Owner and the Scrum Master will continue to develop the Product Backlog in preparation for the next Release. By the start of the second Release, there will need to be enough prioritized Stories (including Impediment Resolutions and Technology Spikes) for that Release.

Here's a possible outline for Sprint Zero:
Describe final product
Create a team(s) workspace(s)
Determine the length of sprints
Identify business value (the criteria to measure the value of work as it's done)
Create epics. Prioritize epics (consider relative business value)
For the highest priority epic, turn the epic into stories
Prioritize the stories (consider relative business value)
For each story, create a definition of done

Describing final product

The vision of the final outcome will continually change, and this adaptability is what Scrum is designed for. To minimize too much front-loading of visioning work, focus your vision on the next product version, and envision a product with minimum functionality that addresses a narrow set of customer needs. Quickly release a first product increment, or demo it to customers and users to validate the vision. Listen to the responses to see if you are shooting for the right goal. Then adapt.

Selectively describes the product at a coarse-grained level, capturing the product’s essence. Answer the following questions:
• Who are the product's target users?
• Which needs will the product address? What value does the product add?
• Which product attributes are critical for meeting the needs selected and therefore for the success of the product? What will the product roughly look like and do? In which areas is the product going to excel?
• What are the sources of revenue and what is the business model?

To what extent should a few of these processes be pulled into the normal Sprints?

==OSE [[GVCS]] Scrum==

First, we list the projects, in order of priority. See GVCS graphic on the right. Changes are: remove pyrolysis oil and [[Babington burner]] with biomass [[Pelletizer]] for fueling modern [[Steam Engine]]s. The burner is already present in the form of the [[:File:Gasifiericon.jpg|Gasifier Icon]]
[[Image:Slide1Linz7.jpg|thumb|40 [[GVCS]] technologies.]]
#CEB press - [[Full Product Release]] achieved.
#LifeTrac - on Prototype II
#Soil Pulverizer -

==See Also==

* [http://www.scrumhw.org/ Scrum for Hardware Product Development] ''Bringing Scrum to the Hardware Product Development Community''
* [http://maccherone.com/larry/2010/02/23/top-10-questions-when-using-agile-on-hardware-projects/ Top 10 questions when using Agile on hardware projects]

[[Category:Project Management]]