1. Frameworks in project management
Waterfall – linear, non-iterative
Spiral design process -- iterative
Agile development
Scrum
Product backlog

2. Waterfall Constant “downstream” flow
Solves problem of “requirements churn” by freezing them
Creates problem of momentum—cannot backtrack when we find problem in original requirements or design concept

3. Waterfall fails at iteration
Requirement specifications change as functional analysis reveals new information:
“now I see the user needs to specify colors of beads, so we designers need a color chooser”
Design Functional Analysis changes as design reveals new information:
“now that we have a color chooser, we see “Black” which is a bad luck color for Ute native americans, and a good color for the Shoshone.”

4. Waterfall fails at iteration
New Requirement specifications “Use a color palette so that users have the option of choosing without “naming” the existence of black beads.

5. How to deliberately incorporate iteration?
Requirement specifications change as functional analysis reveals new information:
“now I see the user needs to specify colors of beads, so we need a color chooser”
Functional analysis changes as design reveals new information:
“now that we have a color chooser, we created a problem with cultural fit”

6. Spiral Design Process
Minimizing project risk by breaking a project into smaller segments
Perform same cycle each time:
Analysis of goals and constraints
Evaluation of options
Development and feedback on deliverables
Plan for next iteration

7. “what needs to be on our radar screen”?
SWOT analysis
Can be used during spiral design process at any point, often useful just to ask
“what needs to be on our radar screen”?

8. Google Charrette 
Jan 2014, Mountain View CA: Designing Google’s diversity computing initiative.

9. Google Charrette Context: what different
situations might we imagine as the context?
Scenarios/use cases: note division between “pull” (their interest) and “push” (our efforts)?
Functionality: requirements follow from use cases.

10. Google Charrette 
Review: What formative evaluations will be needed to keep the design process moving forward?
Parking lot: stuff we can’t deal with at the moment but will clearly need to be revisited.

11. Agile methods Break tasks into small increments with minimal planning
Iterations are “time boxes” or “sprints” -- typically one to four weeks.
Cross functional teams: planning, requirements, design, implementation, testing
Team has responsibility of self-organizing – not controlled by hierarchy
Daily Scrum:
Sprint is long cycle, scrum happens short cycle
If multiple teams, one representative from each attends scrum
In addition to teams:
Scrum master – “servant leader” to remove obstacles
Product owner – voice of customer or stakeholders

12. Product Backlog
Features, functional requirements, bug fixes, etc. - whatever needs to be done
Typically the Product Owner organizes – often use concept of “stories”
Story from one stakeholder
“As a user I want to be
able to search for my clients
by either first or last name; I
don't always know both.”
Different story from different
stakeholder
“As an admin I want to be able
to look at client searches by
users, but I don’t want clients
to be able to do that.”

13. Product Backlog
A product backlog can help us reflect on sources of requirement mismatch: did
we fail to specify this properly, or did the technology fail on what we correctly specified?

14. Product Backlog
Prioritize by attributes such as value to customer and development effort – if something has a small development effort requirement, then higher
the ROI (Return on Investment). In some cases this can be intuitive: