Have Some Meetings
Plan to have a number of meetings to discuss the needs of the project, the roles of participants, and timeline for the work.
- Kickoff Meeting - Discuss the project from a high level perspective and the meetings you are going to have to define it. Identify Roles.
- Design Meeting - Discuss the projects design needs and who is going to be doing the work.
- User Story Kickoff - Introduce the team to Agile/Scrum, MoSCoW, personas, and identify the tools that are going to be used to write your stories.
- User Story Review - Review your project planning work. Review, delete, refine, or spit up user stories into desirable and actionable issues.
- Budget & Timeline - Evaluate your budget and timeline to plan to execute your project.
Project Kickoff
This is a meeting where you and your team will discuss the schedule of meetings to be held, your organizations mission, the projects relationship to your organizational goals, and the tools and methodologies that are going to take your there.
Organizational Goals & Success Indicators
Affirm or define organizational mission. Relate organizational mission to project and identify how the project is going to support that goal or measure the success of the goal.
Identify high level indicators of success for this project.
Example:
- Users can find organization related events.
- Users can read organization news and information.
- Organizational partners are identified and traffic flows from our site to theirs.
Pick a Method
Discuss project planning methodology to be used. We use Agile/Scrum. If you have another methodology that works for your team, use it.
Other Methods:
- Crystal Methodology
- Waterfall
- Kanban
Make sure your team understands the method that you are using and how to participate in the process.
Tools for Running a Project
Discuss tools that can or will be used to manage and carry out the project.
We use JIRA to manage our projects.
Other Tools:
- https://taiga.io/
- Google Sheets
- https://www.scrumdo.com/
- https://trello.com/
Identify Roles
A RACI Matrix is a good way to do it.
- Responsible
- Accountable
- Consulted
- Informed
Plan your next meeting, assign homework, and have someone take notes and send out meeting minutes.
Homework:
- Gather examples of other sites and applications that you like
- Start gathering a wish list of project wants and needs
- Research your selected project methodology
Have someone take notes during your meetings and email out Meeting Notes afterwards.
Meeting Minutes:
The Design Meeting
Do you have any custom design needs?
The SiteFarm design out of the box gets you into compliance with university brand guidelines.
Generally you want to sub-theme if you have branding needs outside of the university design requirements.
If you do, who is going to do it?
Do you have an in house designer, are you using IET Web Dev, or are you using an approved vendor?
Wireframe and Design Tools
We use Lucid Chart and Adobe Illustrator for our wireframe and mockup needs.
Other Tools:
- https://balsamiq.com/
- https://www.gimpshop.com/
User Story Workshop
The goal of this meeting is to explain the format in which you are going to identify the work to be done. Make sure everyone understands the format and place they are going to be created, and leave this meeting with the goal of identifying all needs or possible needs of the project.
Personas
Personas are fictional characters based on firsthand knowledge of your target group.
Get out there and talk to your users. Begin building personas.
- Picture and Name
- Details
- Goals
You can then use these personas to start writing user stories.
Writing a User Story
As a (Persona), I want to (Do Something), so I can (Accomplish a goal).
It's good practice to start writing user stories on flash cards or post it notes. This will allow you to identify duplicates, group related issues, identify dependencies, and reduce overly broad stories into actionable ones.
MoSCoW
Make a list of needs and wants for your new site or applications and then organize them by:
- Must
- Should
- Could
- Wont
Entering User Stories
As mentioned we use Jira. So this is where we would explain how we want User Stories entered and organized.
Issue Type:
- Story
- Bug
- Task
Version:
- Phase 1
- Phase 2
- Phase 3
Epic:
- API Integration
- Event Finding
- Content Migration
Description: A quick description of what is meant by the user story.
Definition of Done: This is the technical description of how this user story is going to be met and marked as complete.
Story Point Estimate: Estimate the effort involved as a 1, 2, 3, 5, 8+
Priority:
- Blocker - Absolutely cannot finish this Version/Phase without this.
- Critical - Could finish this Version/Phase without this, but user experience would be severely compromised.
- Major - Would really like to have this done this phase. It is imperative to the functionality and user experience.
- Minor - This is not imperative to the functionality of the site or user experience, but we would like to have it.
- Trivial - Meh... If you have time, knock this out for us please.
- Not Prioritized - This needs to be given a priority or moved to another Version/Phase for later prioritization.
Assign Homework
Go write user stories.
User Story Review
How To Review A User Story
Is this Story Too Broad? Is This Story Actionable?
It's easy to write a user story that encompasses too much.
As a site manager I want my site to look good so that visitors have a good impression of our organization.
This story is not actionable as it is describing the complete theming process of a site which includes many components and work that can be broken down, defined, and assigned to multiple developers. Try either breaking this into multiple stories or create sub-tasks of this story.
As site manager I want the header to include our logo and a branding accent so that our visitors can tell immediately that they are on our departments site.
See how this story is clearly actionable and can be assigned to one developer while another works on another aspect of the theme.
Reduce or combine duplicates. Does it share a definition of done with another story.
Make Sure User Story Has All Its Parts
- Concise User Story Title
- A Description
- A Version
- An Epic
- A Definition of Done
- An Estimate
What tasks or procedural stories are missing?
These are things like taking the site live when it is ready.
Schedule a Budget & Timeline Meeting
Budget & Timeline Meeting
Verify Budget and Timeline
Discuss the available budget for the project. This is going to dictate how many story points you can complete.
Discuss the timeline for the project. This is going to dictate how many man hours you are going to need to complete the project. The more stories and less time the more people are going to be needed to complete it.
A starting rule of thumb I use is one full time employee can complete 20 story points in a two week sprint. This number can go up or down based on the worker, and the average can go up and down based on the teams ability to complete story points.
Review "Out of Scope" Items
Take a little time to call out any specifics that a worker might assume is part of this project or infer from a user story that is not within the scope of the project.
Review User Stories, Estimates, and Epics
Review the items you have selected for this project and make sure you have the expertise, manpower, and money to complete them.
If you do not, you may need to remove an epic or number of user stories that will need to be completed at a later date.
Propose Sprint Size and Lengths
Based on your user stories, plan out how many and what size sprints you are going to conduct.
- Small Sprint - 1 FTE for 2 Weeks (Can do 20 story points)
- Medium Sprint - 2 FTE for 2 Weeks (Can do 40 story points)
- Large Sprint - 3 FTE for 2 Weeks (Can do 60 story points)
Example Work Schedule:
- Design - 1 Small Sprint
- Development - 2 Medium Sprints
- Content Migration - 1 Small Sprint
- Hardening Sprint - 1 Small Sprint
So in total the project will take you 10 weeks, and just for example purposes let's say an FTE costs you $2,000/wk, and will run you $28,000.