Difference between revisions of "NewYork2008:The Art and Science of Defining Scope"
m (1 revision imported) |
|||
| (6 intermediate revisions by the same user not shown) | |||
| Line 11: | Line 11: | ||
=== Session Notes === | === Session Notes === | ||
| − | |||
| − | |||
| + | '''Project Scope''' | ||
The work that must be performed to deliver a product with specified features and functions | The work that must be performed to deliver a product with specified features and functions | ||
| Line 22: | Line 21: | ||
Objectives: both internal, and external - what we're hoping to do, what users want | Objectives: both internal, and external - what we're hoping to do, what users want | ||
| − | Work Breakdown Structure (WPS): a way to break down the work that's to be done in a an | + | Work Breakdown Structure (WPS): a way to break down the work that's to be done in a an hierarchical fashion |
| − | Project | + | '''Project''' |
| − | + | *Legacy Integration | |
- Filemaker Database | - Filemaker Database | ||
| Line 40: | Line 39: | ||
| − | + | *Graphic Design | |
| − | |||
| − | |||
| − | + | *Site Architecture | |
| − | Can use it for | + | Can use it for trade-off decisions |
| Line 60: | Line 57: | ||
| − | Visual stuff is an important | + | Visual stuff is an important component for agile projects. But for many projects, both visual and text based information is important - many stakeholders can react more effectively to visuals, but programmers often prefer things to be carefully defined in text |
| Line 68: | Line 65: | ||
| − | Developers like this because it forces the staff to give them high level needs rather than specific " | + | Developers like this because it forces the staff to give them high level needs rather than specific "How's", but often the staff want to give the "How's" |
| − | How do you get the list of requirements? | + | '''How do you get the list of requirements?''' |
| − | + | *Thinking through the user needs can help - workshops in thinking through. | |
| − | + | *Feature workshops - workshops are really key | |
| − | + | *Drive to the high level need, not feature desires | |
| − | + | *Important to have think through priority vs. complexity | |
| − | + | *Wireframing | |
| − | + | *Arithmetic is really useful - it really sways people | |
| − | + | *Can vote with a finite budget - sticky dots voting for | |
| − | + | *Ask people what the minimum features things are that critical for the vision | |
| − | How do you effectively get input but still manage the time involvement? For yourself and for the stakeholders? | + | '''How do you effectively get input but still manage the time involvement? For yourself and for the stakeholders?''' |
| − | + | *It's tricky. Break out a core team. | |
| − | + | *One-on-one interviews can be really useful - people will say more | |
| − | + | *Give them something to react to | |
| − | + | *Try to make sure things move forward and it's not a sinkhole | |
| − | + | *Make sure you're really transparent in the process, tell what feedback you want | |
| − | + | *Make sure people feel like you're listening (so try to make sure the things they say are things you can use) | |
| − | + | *Be really transparent about what hat you're wearing - "now this is me as a user", when you're the facilitator. | |
| − | + | *It's important to prioritize the features | |
| − | + | *Sometimes you need to put your foot down and say that more staff time is needed in order to do an adequate job | |
| − | + | '''Sometimes you can talk about things so much that you lose sight about why it's important. And get sign off from fatigue. What can you do?''' | |
| − | + | *Refocus on the priorities? | |
| − | + | *Bring up the timeline and budget | |
| − | + | *MoSCoW can be useful - Must Have, Should Have, Could Have, Not Now | |
Latest revision as of 18:21, 15 January 2016
Description
They say that one of the most common reasons for project failure is poorly defined project requirements. There are many approaches to scope definition, but before we dive in, what do we need to do first? And once we've done those things, how should we proceed?
In this session we will:
- Talk briefly about scope generally – define and discuss it, discuss related terms
- Look at and discuss the usefulness of an age-old scope definition tool – the WBS
- Look at an agilist technique for defining requirements or "stories"
- Use the rest of the time available to share and discuss scope definition best practices
Session Notes
Project Scope
The work that must be performed to deliver a product with specified features and functions
All projects have objective, deliverables, requirements, constraints
Objectives: both internal, and external - what we're hoping to do, what users want
Work Breakdown Structure (WPS): a way to break down the work that's to be done in a an hierarchical fashion
Project
- Legacy Integration
- Filemaker Database
- X
- X
- Static HTML
- Graphic Design
- Site Architecture
Can use it for trade-off decisions
Agile project management is designed to respond to changing requirements, quickly iterative. For instance, for a complex interface, you would quickly get something up so people could react to it. For instance, put up a working prototype.
Some Agile PMs don't like the WPS structure- they find it too static. But it can be a living document, and that helps.
Visual stuff is an important component for agile projects. But for many projects, both visual and text based information is important - many stakeholders can react more effectively to visuals, but programmers often prefer things to be carefully defined in text
In the Agile methodology, you create your requirements in the form of "stories", using the syntax "As a <user name> I would like <what I would like> so that <why I would like it>. Rob used these on a project and generated about 150 different stories, and prioritized them all. "As a content administrator, I would like to be able to create content without knowledge of HTML, so that I can save time by not having to look up the syntax"
Developers like this because it forces the staff to give them high level needs rather than specific "How's", but often the staff want to give the "How's"
How do you get the list of requirements?
- Thinking through the user needs can help - workshops in thinking through.
- Feature workshops - workshops are really key
- Drive to the high level need, not feature desires
- Important to have think through priority vs. complexity
- Wireframing
- Arithmetic is really useful - it really sways people
- Can vote with a finite budget - sticky dots voting for
- Ask people what the minimum features things are that critical for the vision
How do you effectively get input but still manage the time involvement? For yourself and for the stakeholders?
- It's tricky. Break out a core team.
- One-on-one interviews can be really useful - people will say more
- Give them something to react to
- Try to make sure things move forward and it's not a sinkhole
- Make sure you're really transparent in the process, tell what feedback you want
- Make sure people feel like you're listening (so try to make sure the things they say are things you can use)
- Be really transparent about what hat you're wearing - "now this is me as a user", when you're the facilitator.
- It's important to prioritize the features
- Sometimes you need to put your foot down and say that more staff time is needed in order to do an adequate job
Sometimes you can talk about things so much that you lose sight about why it's important. And get sign off from fatigue. What can you do?
- Refocus on the priorities?
- Bring up the timeline and budget
- MoSCoW can be useful - Must Have, Should Have, Could Have, Not Now