Sprint Management

All feedback is reviewed by the project manager and is translated into tickets, and prioritized appropriately. If emergent--such has a catastrophic bug or a tiny feature request to consummate a new client--the work would be immediately prioritized.  If not, the task would wait until the next sprint planning meeting (usually within a week) for proper priority.

The importance of formal adoption, implementation, and use of a good project management tool cannot be underestimated.  Any good project management tool allows us to:

• Break up large projects into small pieces (aka tickets, which can be categorized as bugs, user stories, or tasks)

• Set the priority of each ticket, and assign it to a feature and/or milestone

• Assign the size of the work

• Assign these tickets to developers

• See exactly what each developer is working on, and for how long

• See all the discussion on each task in one place

• See the tickets in order for a new feature or milestone to be completed, and estimated time until completion, and the completion date

• Share with external stakeholders all info they need for 100% transparency in real-time

Strike Labs has made use of several sprint planning tools and historically including 1) Basecamp, 2) Jira, and Confluence -- both of which are made by Assailant and are closely tied together, 3) Notion 4) Monday.com 5) Smartsheet 6) Sprint.ly. 7) Trajectory 8) Trello.  We have also built our own called Strike Paperwork used prodomalty for client communication and deliverables around Statement of Works.

Prioritization

Prioritization, which happens via the product manager before the ticket is marked as groomed, is an essential part to make sure the right work is done at the right time.  Every ticket is marked with a 1-5 rating for importance, time sensitivity, and amount of work.

Tickets that are very important, very time-sensitive, and that do not require a lot of work are prioritized over the opposite side of the spectrum. In the middle, it's more of an art than a science and takes into account dozens of other factors including:

• Product Strategy

• Future Expected Revenue (Increasing Revenue)

• Cleaning Up Poor Experiences / Client Support / Satisfaction (Protecting Revenue)

• Management Dictication / Influence / Request

• Creating Internal Tooling for Increased Operational Efficiencies

• etc.

All stakeholders have the ability to communicate directly with the product manager at any time.  This feedback from the stakeholders is transformed into tickets.  In case of emergencies, we would pivot to address the client’s immediate needs.

New features can likely be added within a few weeks--or sooner--upon request.

Meetings

We have found the following meeting structure to be most efficient:

• Monday Morning Sprint Planning - All user stories are added to a team product management tool, and developers are assigned.

• Daily Stand-ups - With the team to make sure everything is running smoothly

• Strategy Sessions - We also conduct strategy sessions each month, so the entire team understands what the overall strategy of the capability is.

• Weekly Stakeholder Calls - Calls with the stakeholders for anything they wish to discuss.

• Design Sessions - Facilitated by the lead designer prior to beginning a new feature.

• Stakeholders Roadmap Meeting - Formal monthly meetings with stakeholders to confirm feature-level prioritization

Stakeholders are welcome to observe all meetings.  Roles and responsibilities will be clearly detailed to everyone in each meeting to clear up ambiguity.

Ticket Stages

No matter the tool, every ticket goes through the following steps, in the following order:

1. Backlog - all tickets start here.  No work is done without being assigned a ticket.

2. Groomed - once all the details, requirements, and assets are collected, the ticket is marked as groomed, tagged with a larger piece of work, sized, and is prioritized against other tickets.

3. In Process - these are all tickets that are actively being worked on by a developer.  Each developer should only have one ticket in progress at the same time.  It is at this stage that additional engineering tests are completed.

4. Completed - Once the development work is complete, the developer moves it to complete, for an independent project manager to test, and the developer is allowed to begin a new piece of work.

5. Accepted - Upon a successful test, the project manager marks the ticket as complete. If the test fails, it is moved back to In Progress.

6. Pushed - Once the code for the associated ticket is deployed to its users, (aka “Pushed to Production”, “In Production”, or “Pushed” ) the ticket is marked as pushed.  To get an understanding of velocity, we deploy many times a day.

Ticket Sizes & ETA

• Every chunk of work is broken down to its smallest possible level that can be defined and are entered as ticket. Everything gets a Ticket.

• Each ticket is given a T Shirt Size. XS, S, M, L, and XL.

There are 518 development hours to complete the feature. Assume that every developer works 40 hours per week, this could be accomplished by X number of developers for y months.

• 518 developer hours needed / 1 developer working 40 hours a week = 13 week until completion.

• 518 developer hours needed / 2 developer working 40 hours a week = 6.5 week until completion.

• etc.

Table below shows the effect of adding more developers.

1. If timing is a factor (sooner the better), then the number of developers will need to be ramped up. Example, it if is needed in 4 weeks, you will need to have more than 3 (518/40=3¼) developers cranking to deliver the feature in time.

2. If the number of developers are a static, then timing for the work can’t be adjusted and the product/project owner will need to be made aware that since you have 2 developers, it will take about 6.5 weeks for delivery of the feature.

3. If neither the dev team size nor the duration can be adjusted, then you will need to start removing tickets and/or have a hard conversation with the owner.

Capturing Feedback

One of the largest inputs to our traditional development process is feedback from the users.  We collect this feedback in the following ways:

• User analytics, using Mixpanel or KISS Metrics, both powered by Google Analytics in order to capture all user behavior.

• Feedback boxes, customer support telephone line, live chat popup, and slack groups on all the capabilities we build.

• Giving users the ability to add new and up/down vote feature requests.

• Formal beta testing groups can access the new features first and provide feedback before these features are rolled out to the larger group.

• Bringing in external professional UX/UI designers for a working session to determine what could be made better.