PM Handbook @jabondano

Frameworks

Automations

Digital Marketing

PM Lectures & Videos

APIs

Explore

Development

How-To Guide: Product Development & Release Management

⁠

Gannon Hall⁠

⁠

Apr 18, 2018⁠

· 20 min read

Contributor:

Mike Nobil⁠

⁠

The goal of a development and release management process is to provide guidelines to help improve the flow of information, accountability, quality, and velocity of software releases. The goal is not to impose executive oversight or control. On the contrary, tight product planning and release management enables more empowerment at the lead level and helps prevent unplanned projects from derailing the roadmap.

These guidelines borrow practices from a variety of sources but can best be described as a variant of the agile scrum methodology.

Adopting a quasi agile scrum methodology does not mean that you should favor speed over quality. If a feature isn’t ready you shouldn’t release it. Ideally, changes/fixes that address the feature’s “readiness” will be made and the feature will be released in the next sprint.

Product Squads

Squads are an autonomous unit of PMs, engineers, and designers primarily responsible for a portion of the user experience or business function evident in their squad name. A squad should have at least 1 PM lead, 1 Engineering lead, and 1 Product design lead. Squads use

OKRs⁠

and sprints to represent the impact of the work they do to continuously improve a user’s experience.

Planning Milestones & Development Sprints

Weekly Product Review Meeting

Product review meetings are a weekly meeting to review plans and works in progress. The purpose is to inform, discuss and decide on a range of initiatives in different stages, with the goal towards keeping each other informed, gathering feedback and building consensus on next steps. This is the meeting where

Feature Briefs⁠

, critical updates that cause roadmap changes, designs, and demos are reviewed (along with a variety of other points of interest).

Stakeholders should consider product review meetings their primary source of product information and their primary opportunity to provide feedback on product direction and functional design. Product should make this opportunity a priority. It is vital that relevant stakeholders outside of the tech org are involved as early as possible. With that said, if a stakeholder chooses not to attend a meeting or engage in the process, they forfeit their input.

Major Initiative Kickoff Meeting

The major initiative kickoff meeting happens once as a squad begins to design and scope a Major Initiative. It is where a

Feature Brief⁠

, that has been given the go-ahead to continue exploration after a product review meeting, is broken down into design, analysis, and engineering tasks resulting in artifacts such as wireframes, EPQs, and/or user research studies. Tasks identified in designing and scoping the initiative are assigned during this meeting.

A squad’s lead PM, lead engineer, lead analyst, and lead designer are required to attend this meeting while optionally inviting stakeholders and other key designers/engineers/analysts who are likely to be significantly impacted by the Major Initiative or take on tasks coming from the

Feature Brief⁠

. If a stakeholder chooses not to attend a meeting, they forfeit their input.

Design Review Meeting

Design review meetings have 3 possible subjects: visual/UX design review, user research review or technical design review.

Invitees should include all squad leads (engineering, product & design) or their chosen proxies, and all stakeholders likely to be impacted or interested. Lead Product Managers, Engineers, & Designers have the responsibility of encouraging stakeholders who are likely to be interested to attend.

Regardless of the format, the purpose of the review should be made clear by the Lead Product Designer. The designer should also make it clear what kind of feedback they need for from the group.

The feedback gathered may lead to additional design and/or research tasks to be created. The Lead Product Manager should work with the Designer and/or Researcher to estimate the level of effort (LOE), and plan the next review accordingly.

The design review meeting can happen any number of times between the major initiative kickoff and feature planning meetings. The number of times this meeting happens is at the discretion of the lead PM based on his or her judgment of when the squad is prepared to begin work on any part of a major initiative.

The lead PM is responsible for clearly communicating, to all interested parties, when a scheduled design review meeting will involve making a decision on design finalization.

Feature Planning Meeting

The major initiative planning meeting is where Stories in a technical design and/or UX specs are translated into Tasks and estimated using Story Points. This meeting is scheduled on an ad hoc basis, and typically should happen once for a Major Initiative, and usually covers several weeks of work for an entire team.

Feature Planning is led by a PM and involves an engineering lead and the engineer(s) who will own at least one task from the technical and/or UX designs. An effective practice is to have a PM walk through UX Designs and prompt engineers to break down each part of the design that requires a Task, or the lead engineer talks through the technical design to prompt the PM to create tasks for each component of architecture, logic and/or implementation.

Sprint Milestones

Sprints are 2 weeks periods in which all tactical work for major initiatives and features is completed.

Example Sprint Calendar

⁠

No Meeting Day

In the Sprint calendar above you’ll notice that I’ve designated Weds as a “no meeting” day. While managers often have to break this rule, the goal is to dedicate at least one day a week of uninterrupted work. I have found that this practice contributes greatly to productivity.

Sprint Kickoff Meeting

Sprint kickoff is comprised of two primary activities:

Preparing for the Sprint kickoff meeting

Moderating the Sprint kickoff meeting

Preparing for the Sprint Kickoff meeting

In the days and weeks before a specific sprint kickoff meeting, the following activities should be completed:

Weeks before Sprint

Finalize technical designs

Finalize UX specs (when applicable)

Features (or “Epics”), Stories, and Tasks are drawn from the product feature brief, technical designs, and UX specs, prioritized, and added to a Backlog (Feature Planning meeting).

Days before Sprint Kickoff Meeting

PMs meet with their squad to prioritize and estimate all backlog stories, tasks, and bugs in a Backlog Grooming meeting,

Forecast squad velocity for the forthcoming sprint.

Sprint Kickoff Structure and Agenda

The Sprint Kickoff Meeting happens on the first day of the Sprint, which is also the last day of the preceding Sprint. It includes all members of a squad (PM, Engineering, Design, Data Science).

The goal should be to spend minimal time in the actual Sprint Kickoff meeting. The PM should come to the meeting with a prioritized backlog of dev ready stories and tasks along with a calculated squad velocity. Sprint kickoffs generally take about an hour for each week of work, but one should endeavor to reduce that time to 1 hour. Preparation is key. The more prepared, the shorter the meeting.

Velocity Calculation

Using story points, you can get an approximation of how much work a squad can realistically complete in a single sprint. In order to normalize for the ebb and flow of squad output, use an average of story points completed in the past 4 sprints to calculate a squad’s velocity. That velocity is then discounted based on team members actual availability, taking into account things like vacation time, to forecast the number of story points a squad can complete in an upcoming sprint. The calculation looks like this:

Velocity = (Sum of completed points in the last 4 sprints) / 4 (1 - (Count of squad member days / total squad member days))

The PM should strive to continually optimize the meeting for efficiency. This is a tactical meeting, strategic discussions should be avoided. If strategic questions come up, acknowledge and make note of them for later discussion.

Meeting Agenda

Previous sprint retrospective

Did we achieve the objective/goals we set for the sprint

What went well with the sprint

What could we have done better going into the sprint and/or during the sprint?

Convert learnings into action items to be applied to the forthcoming sprint (and beyond)

Reframe the problems evident in the squad OKR and how the feature being worked on should address the problem for the user and impact KR(s)

Outline any new information gained that may alter the team’s perspective on addressing the problem and/or the OKR

Discuss any new information that may impact the sprint

Confirm team capacity

Pull stories and tasks from the Backlog into the sprint that approximately reflect team capacity

Review acceptance criteria for each story and make any appropriate updates based on technology, skill, or team member changes since the last sprint

Determine the needs, sign up for work, and verify estimates of the work owned

Create overarching goal(s) for the sprint (1–4 bullets that encapsulate the goals and intended results)

Call for a group consensus on the sprint commitments and goals considering the feasibility and extenuating circumstances.

Daily Stand-Up Meetings

On each day of a sprint, the team holds a daily meeting called the “stand-up.” Meetings are typically held in the same location and at the same time each day. Ideally, stand-ups are held in the morning, as it helps set the context for the coming day’s work, but there is no specific requirement around this in consideration of remote teams working in various timezones. These meetings are strictly time-boxed to 15 minutes. This keeps the discussion brisk but relevant.

Anyone in the org can attend any stand-up, however only those directly involved in the sprint may speak.

The daily stand-up is not used as a problem-solving or issue resolution meeting. Issues that are raised are taken offline and dealt with by the relevant subgroup immediately after the meeting.

During the daily stand-up, each team member, moving from person to person in a consistent manner (clockwise or counterclockwise) answers the following three questions in sequence:

What did you do yesterday?

What will you do today?

Are there any blockers in your way?

By focusing on what each person accomplished yesterday and will accomplish today, the team gains an understanding of what work has been done and what work remains.

The daily stand-up is not a status update meeting in which information is collected about who is behind schedule. Rather, it is a meeting in which team members make commitments to each other.

If an engineer says, “Today, I will finish the new data module,” everyone knows that in tomorrow’s meeting, she will say whether or not she finished. This helps the team realize the significance of these commitments, and that their commitments are to one another, not to a company executive or business stakeholder.

Any blockers that are raised in the stand-up become the PM’s responsibility to resolve as quickly as possible. Typical blockers include:

I need help debugging a problem with X.

I’m struggling to learn X and would like some help.

I can’t get the vendor to call me back.

X is on vacation, and no one knows how to do Y

I can’t get the X team to give me the information I need to compete Y

X has asked me to work on an off roadmap project “for a day or two”

In cases where the PM cannot remove these impediments directly, she still takes responsibility for resolution, and if necessary, escalation.

Backlog Grooming

Backlog grooming meetings occur opposite sprint kickoff meetings and aim to be just as efficient with squad time, if not more-so. These meetings aim to ensure all squad members:

have the opportunity to thoroughly understand stories and tasks that will be added to a sprint at some point in time;

suggest additional stories and tasks;

suggest removal of stories and tasks if they are no longer relevant or the squad believes they won’t be addressed in the next 4 months;

estimate the work involved in completing each story or task using Story Points;

collaborate on setting the priority of addressing each story or task in preparation for the forthcoming sprint kickoff (and beyond).

The end goal of Backlog Grooming is to gain squad consensus on story point estimates and prioritization of the entire backlog. If that goal is achieved, in the interest of effective time expenditure, squads should cancel backlog grooming meetings until consensus is lost and/or new information, stories, or tasks are gained.

At least a lead PM or lead engineer plus one engineer is required for a backlog grooming meeting. Ideally, the entire squad will attend backlog grooming meetings in order to gain the most benefit from the time spent.

Story Points

Story points are abstract with no direct representation of time

Story points are estimated based on engineering’s perspective of relative complexity (relative to all other stories/tasks that have previously been estimated) and confidence in their understanding of implementation requirements

Story points use a

fibonacci scale⁠

from 1–13

Stories/tasks that are estimated at an 8 or 13 should be broken up into multiple stories/tasks, if possible

Story points are assigned to a story/task by at least 2 engineers using the

Poker Planning method⁠

On first estimation, each team will create a straightforward and familiar task and assign it 1 point. This task will serve as the benchmark for estimating all other tickets until the engineering team has a common understanding of the relationship between complexity/confidence and points.

Sprint Updates

Sprint Updates should be sent companywide by the On Call PM, who sends a Sprint Update after each sprint kickoff. If your company is relatively small (under 200 people), the updates should be sent company-wide. Sprint updates should communicate progress on OKRs across all squads along with major initiative or feature specific status updates. Not all sprints will include user-facing features; regardless, sprint updates should be distributed for each sprint.

A Sprint Update should include the following:

Executive summary highlighting key takeaways from the sprint

Status, next steps, and percentage complete for each feature under development (using a color coding system such as yellow for minor risk, red for major risk and green for no risk are useful when communicating at-a-glance status information)

Bugs reported

Feature requests received since the last update

It is useful to maintain a historical record of each update so I would recommend using a Google Group (or similar) email list, explicitly for this purpose.

Release Management

During “Internal Testing” a formal sign-off process should occur. A squad’s lead PM is responsible for ensuring that all required parties sign-off on the release prior to its public launch. If there are issues acquiring sign-off, the lead PM should escalate as appropriate. However, as the team becomes more effective as collaborators escalation should rarely be necessary.

Internal Testing Preparation

Engineering continues to commit code to production, however, all committed code (user-facing or not) sits behind a

feature flag⁠

⁠

Bug fixes are deployed and made live as needed

Functional bugs require PM review to ensure the feature is functioning as

intended

For Internal testing, feature flags, and a domain-based whitelisting system should be used to make it easy to enable a feature for employees only

Internal Testing Execution

Once a feature is available to employees behind a feature flag in production and the lead PMs have QA’d the feature:

The lead PM will email Release Notes to the company

Release Notes should include:

Overview of the feature(s) being released

Request for assistance testing the feature(s)

Instructions for how to test the feature(s)

Instructions for how to submit feedback and bugs (release-feedback@)

Target date for starting feature rollout to users

Deadline by which feedback and bugs must be submitted

Lead PMs (and QA Analysts when available) vet and respond to bugs and feedback submitted by anyone in the company

Lead PMs prioritize vetted bugs and feedback in the backlog

Feature launch date extensions are at the discretion of the lead PM with consideration for feature value delivered with or without addressing vetted bugs and feedback.

Should reported bugs and/or feedback delay the target date for feature rollout, the lead PM will notify the company of the cause and revised target date for feature rollout.

The following sign-offs should be obtained before features become public:

Lead PM

Lead Engineer

Business Analyst

Product Design Lead (front end impacting only)

QA Lead (when available)

Primary Stakeholders (including Privacy, Security, Legal and PR)

Sign-offs and Release status should be managed on a Release Management board

Post-Release Impact Analysis

After the launch of a new feature, PMs should:

Finish building out dashboards to track all success metrics defined in the Feature Brief

Perform a deep-dive analysis on product impact ~30 days after launch and distribute to relevant stakeholders

Identify potential product improvements based on the performance data.

30-day Impact Assessment

The 30-day product impact assessment should go beyond restating or summarizing the performance dashboards. PMs should work with Product Analytics to perform a deeper analysis to better understand:

Performance to date against success criteria outlined in the feature brief

Impact on the squad KRs

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.