Skip to content

Latest commit

 

History

History
138 lines (92 loc) · 7.25 KB

File metadata and controls

138 lines (92 loc) · 7.25 KB

#Project Agreemet

##Workshop Meeting Details The team met to discuss {the project name}. The results from that meeting are included in this project agreement document that describes the vision and path for the proposed project and includes an estimate to complete the core feature set agreed upon in the meeting.

##Meeting Date {date & time}

##Attending Approximately {#} stakeholders attended the four-hour workshop consisting mostly of {which departments, area, etc…}. The facilitators were {facilitator names}.

##Project Overview {A brief description of the project with minimal technical details, some may be needed.}

##Project Objective The following objective is the vision for the project as determined by the group at the meeting. The objective’s purpose is to help guide the project for the development and stakeholder team and limit the risk of veering off course with features and tools that don’t contribute to this overarching vision.


{objective}
______________________________________ ##Project Stakeholders Everyone who has a stake in whether the project succeeds is a stakeholder in the project. This includes members of both the customer and development team. The following stakeholders were identified for this project:
Name Project Role Project Stake Project Duties
Project Sponsor (Customer) Help deliver on promised business functions. Contributes to and verifies project definition, scope, and management. Provides direction and vision for the project.
Project Owner (Customer) The primary contact for the development team. Contributes to project definition and priority. Main point of contact to clear roadblocks and get answers to questions. Organizes necessary meetings, attends development meetings and demonstrations.
Project Manager Manage the process of the project. Facilitate feature and prioritization changes, ensure the development process is being followed, setup necessary meetings and ensure good communication.
Lead Developer Lead the team to develop the code. Understand the features and their context, lead the development team in the implementation, demonstrate the features periodically to the primary stakeholders.

##User Roles The group considered what types of users would use this project and came up with the roles listed below. These roles were used later in the meeting to help the group think about the features the project could have from the perspective of each of these types of users.

Roles

  •  
  •  
  •  
  •  
  •  
  •  
  •  

##Assumptions and Constraints During the meeting we brainstorm a lot of features we would like to have and do not have time to explore whether some aspects will be possible; therefore, we try to record any assumptions we are forced to make so that we can revisit them later. Likewise, we may hear about restrictions on the project like budgets, timelines, or technology that must be used and we try to record these as constraints.

The assumptions need to be monitored and managed so that the risk they represent can be managed proactively. The constraints are important to communicate to the team so that everyone knows where the boundaries lie and don’t waste time working on the wrong side of the line.

During the meeting we identified the following assumptions and constraints: ###Assumptions

  • {Assumption 1 – Ex: Marketing is out of scope, licensing is taken care of}
  • {Assumption 2}

###Constraints

  • {Constraint 1 – Ex: Time, budget}
  • {Constraint 2}

##Features Everyone participated in the brainstorming session to identify what features they wanted to include in this project. All of the features are included as an attached Excel spreadsheet.

The features were recorded in a specific format that encourages the consideration of:

  • As a {user role from list above} (who wants this feature; from their point of view)
  • I want (description of the feature)
  • So that (description of the business or other value of this feature)
  • This is done when (explain how we know when this feature is complete)

##Core Feature Set By this point in the meeting, the group has agreed on a vision for the project and everyone has had a chance to contribute to the most important features the project should include. All of the features are valuable, but we want to take that cloud of ideas and condense it into the core set of features that by themselves make the project worth doing.

We want to identify this core feature set and complete it first because we will learn so much about the real needs and priorities of the project by the time people start using these features that we will want to revisit our feature list and priorities to make additions and substitutions.

First, the product owner and sponsors reviewed the features and ranked them by priority for how critical they were to the success of the project.

Next, each customer stakeholder was invited up to the whiteboard to draw a line on the board separating the features that had to be completed to make the project worth doing from the features that were important, but just nice to have.

Finally, the product owner and sponsors considered where each group drew their lines and agreed on one divider line to define the core feature set.

The features below were identified as the core feature set for this project. All features that were identified in the meeting can be reviewed in the attached Excel spreadsheet.

Rank# As a I want to So That Acceptance Criteria
1 {role} {some feature} {specific reason} {criteria for the definition of work complete}
#Project Delivery

##Process We will work on this solution in a number of iterations each three weeks in duration. At the beginning of each iteration the development team will work with the product owner to adjust the iteration backlog to make any additions or substitutions. On completion of the iteration, the development team will present the completed functionality to the customer stakeholders for their review and feedback.

##Schedule For the features identified in the core feature set, we estimate the entire effort should take {four-to-six iterations, which will take twelve-to-eighteen weeks}. This estimate is for budgetary purposes only and we will update the estimate at the end of each iteration based on the progress. Typically within two-to-three iterations we can estimate the project duration with a high-level of accuracy.

The development team can begin work within three weeks of project agreement and sign-off.

#Customer Project Agreement

  ________________________ Project Sponsor – {name}

  ________________________ Date

 

  ________________________ Project Owner – {name}

  ________________________ Date

#Developer Project Agreement:  

  ________________________ Project Manager – {name}

  ________________________ Date

 

  ________________________ Lead Developer – {name}

  ________________________ Date

 

  ________________________ CTO – {name}

  ________________________ DAte