I.D. Project Strategy & Implementation Phase Specifics

Project Terms

Sprint: A set period of time during which specific work is completed (most typically 2 weeks). Sprints typically start at the beginning of implementation, and continue until project completion. Sprints break up work into manageable chunks and help gauge progress toward release dates. Sprints are for the internal management of work, not the external management of work and do not necessarily correlate with release dates or when something will be visible to a client.Key things to remember:
- Once a sprint is over, any remaining work simply is carried forward into the next sprint and assigned work is adjusted as needed
- The sprint cadence of meeting every two weeks helps keep everyone informed and in collaboration with each other.
- The work assigned in a sprint should be feasible to complete during the sprint based on available time and estimated hours, as well as time needed for QA, documentation, and deploys of client releases.
- For each sprint the PM should determine the amount of resourced time available for each member of the team accounting for vacations, holidays, allocations to multiple projects, etc.
Release: A collection of features, components, elements, templates that will be developed (front and back end), documented, tested, deployed to staging and may include training the client, so that the client may enter content into staging. Releases are tied to a date range and are planned out before the start of implementation.
- One or more sprints may be needed to complete a release.
- A release may happen in the middle of a sprint, that is expected.
- The order and dates of releases takes into consideration both the design/development needs of building a theme, and the content needs of the client.
- A release in this context is for the client, and while it may often map directly to a numbered release in github, it does not prevent deploys of the theme as needed by the team.
- Code and functionality that is part of a planned release may be merged and deployed prior to that release. The planned client release is when we’ve planned to have it complete for content entry and ready to share with the client in Staging.
- Releases are planned during estimation of a project:
  1. At a high level by the ACD to segment and order the work
  2. The team reviews it, provides feedback, and adjusts the releases ( designer, developer, content )
  3. Provide the release plan to the project manager to build a project schedule.

Introduction

Use GitHub to track implementation details as soon as the team begins planning them. This often begins in strategy during a Strategy + Planning project, or as part of planning in an enhancement or small to medium project without a formal strategy phase.

During Strategy & Planning

When the project kicks off

The creative director will work with the team to determine if an existing GitHub repository will be used or if a new repository needs to be created. See: Repository Configuration

During wireframes

The creative director will work with the content coach, if one is assigned, the designer, the developer, and the project manager to start planning client releases.
Determine as much as possible what planned releases will be needed during implementation based on known features and project needs.
This initial planning can be sketched out by the creative director in GitHub using milestones, or in Smartsheet as a start to an Implementation Schedule, depending on the creative director and project manager’s workflow preferences.

When wireframes are approved

The creative director will set up GitHub Projects and milestones according to the project configuration.
- Use the release planning work from the last step to set up milestones
- The creative director may add issues at their discretion for custom Features to guide the team in discussing general structure and begin brainstorming components and connections. These issue will serve as the source of truth for estimating any custom development work that needs to happen on the project.

When estimation is complete, the team will…

Finalize the planned client releases:
- The creative director will ensure necessary milestones are setup for each planned release, with a high level description of what is in that release
Ensure all estimated items in the Estimation Sheet have a corresponding Github Issue
- The creative director has cloned over any default issues from the ID Github Setup repo
- The creative director has created Feature issues for any items that need discussion and/or custom development work. These issues at the minimum include a descriptive title and/or a high level description.
- The designer and developer have created any child issues related to that Feature issue and linked them in the description
- The designer and developer have created issues for all the remaining items on the estimation sheet that were not covered in the previous 3 bullet points
- The creative director has assigned all issues to a Release Milestone
- The designer has:
  - Added business or front end requirements to all issues
  - Linked wireframes and/or mockups to all corresponding issues
  - Asked any questions of the creative director required to understand the goals so that they are prepared to answer questions from the developer
  - Passed on to the developer where custom development is required
    - This can be done asynchronously through Slack or in working meetings between the designer and developer on Zoom, depending on team workflow preference.
- The developer has added technical or back end requirements to all issues requiring custom development
- The team has added the appropriate labels to all issues while writing requirements
- The team has added hours to each issue based on the estimation sheet
The creative director will then verify that the items above were completed and work with the project manager to:
- Create a schedule using the Planned Client Releases and other project milestones
- Ensure a Smartsheet Backlog is created with all of the same Github Issues

During Implementation

Implementation Planning + Responsibilities

The project manager will set up recurring project meetings:

A Sprint Planning Meeting between development team members will occur every 2 weeks
On the opposite week of the sprint, a Project Checkin Meeting of the entire team will occur.

Before the Sprint Planning Meeting or Project Checkin Meeting:

Designers & Developers will update the % complete columns in the Github Project to reflect an approximate estimate of their progress on each issue in that Sprint.
- Add progress in 10% increments: 10%, 50%, 90%, etc.

At the start of each sprint

At the start of each sprint, a Sprint Planning Meeting will:

Review progress in the previous sprint.
Review progress overall to determine how much time is available for the following release
- May be different per skillset and allocation to the project
Identify the GitHub Issues necessary to continue progress on the current Release and assign them to the next planned sprint
Identify GitHub Issues for the next sprint, and the following sprint after that
Discuss progress on any blockers or issues
At the end of this meeting, the Github Project would have an accurate list of the planned work in the next 2 sprints.

Updating the sprint board

The project team ( designer, developer, and/or the creative director ) is responsible for updating the Current Sprint Board in Github:
- Before the meeting, the creative director will:
  - Archive or remove issues in the completed column.
  - Assign or reassign issues to sprints and milestones.
  - Add issues for the next sprint to the To Do column in their best understanding of order of priority to complete from top to bottom.
- During the meeting, the creative director will:
  - Introduce the general goal of the sprint (for example: complete a feature for client entry)
  - Introduce the general order of priority in the To Do column, and facilitate a discussion about tasks between the designer and developer regarding:
    - Order of priority
    - Designer/developer – who goes first
    - Questions about the work
- During the meeting, the designer will:
  - Update issues with any new business requirement decisions made in-meeting, using the issue description (not comments).
  - Review the order of priority in the To Do column with the developer, and reorder their tasks if necessary
- During the meeting, the developer will:
  - Update issues with any new technical requirement decisions made in-meeting, using the issue description (not comments).
  - Review the order of priority in the To Do column with the designer, and reorder their tasks if necessary
- This must happen ASAP so the Github board is in sync with the decisions made in the Sprint Planning Meeting.
Immediately after the meeting, the creative director will add issues for the following sprint to the On Deck column in the order of priority to complete from top to bottom.

During each sprint

During a Sprint, while working in the current sprint board:

When you are ready to start a task:
- Assign an issue from the To Do column to yourself
  - Do not assign issues to others.
- Move the issue to the In Progress column
As soon as tangible work has been produced:
- If code:
  - Push your new branch to GitHub
  - Open a draft pull request and reference the pull request link in the related issue to connect it
- If design or wireframes:
  - Create an Adobe XD share link and reference it in the issue to connect it
  - Invite the creative director to coedit the file so that if you need to take a sick day or vacation time, the creative director can help keep your work moving
When all work that can be completed at this point on that Issue is done:
- Move the Issue to In Review on the board
- If code:
  - Change the pull request from Draft to Ready for Review
  - Request a review in the #code-reviews Slack channel
- If design or wireframes:
  - Send your Adobe XD share link to the Creative Review Needed Smartsheet
When you receive approval:
- If code:
  - Merge your pull request
- If design or wireframes:
  - Notify the Slack channel, if appropriate
- All work types:
  - If no work remains on that Issue during this sprint:
    - Move the Issue to Done and remove your assignment on the Issue.
  - If additional work by a colleague is needed on this during this sprint:
    - Move the Issue back to the To Do column.
  - Update the labels on the Issue to add / remove “Needs Frontend” or “Needs Backend” as appropriate for the remaining work needed.
Return to the first step and repeat.

Project Questions?

For technical, visual and business questions: contact your project’s Associate or Assistant Creative Director.

For allocation and timing of deliverables on a project: contact your Project Manager.

For prioritizing your entire workload: reach out to your Managing Supervisor.

When changes arise during a sprint

Adding Additional Issues

Out of scope changes: consult with the project manager & creative director before adding new issues that are out of the original scope of the project and planned work. These should almost always be accompanied by a Change Request to the original project SOW.
Minor tasks, or subtasks of existing planned work: everyone on the team should feel free to add these as needed to keep themselves organized and track small items during implementation.