As big believers in Macro Management, we value the Teams independence and give them freedom to be creative at their own (s)pace, all within the boundaries of a very meticulous project management process.
To ensure Milestones are met on time and on budget, we encourage constant Communication between the Team and the Client, thus increasing the chances of a very successful project.
Milestones mark specific points along a project timeline, usually a Product Release, an important iteration or a major Deliverable. Simply put, it's a reference date that denotes a major event in the project.
In our case, each Milestone is comprised of OKR's and a set of features that will make those OKR's viable.
But sometimes our clients don't have a clear understanding of what those Milestones can be, and starting to Develop a Product without a clear vision on where to go can be deadly harmful.
That's when we step in.
Founder at Backercamp
You can reach out to them with just an idea or a paper brief, and they will help you figure out the best way to make it happen.
Defining an MVP
When it suits the case, we start by helping the client defining the MVP. Beyond imaginable, defining a well-thought-out MVP can be crucial for successful, long-living, sustainable products.
Being able to define an MVP is a matter of mind-set, a matter of being able to detach our emotions from the Product and being capable of setting apart the absolute fundamental functionalities from the nice-to-have.
In most cases, an MVP is made of the features without which the product couldn't exist. As an example, a Marketplace without Payments.
As an exercise to get to that level of detachment, during a Workshop, we jump to the white board and we draw two columns. On the left hand side we have the Must Haves, on the right hand side the Nice to Haves.
It is an iterative process that requires a deep understanding of the Product, there's a lot of back and forth and discussion but in the end there will be a first version draft of that the MVP can become.
Once the MVP is signed, sealed and launched, new features will come along. Some come from the assumptions that building a feature will improve the product, some come from user feedback, some come simply from our own beliefs. But deciding what to do next can be tricky sometimes: the resources aren't unlimited and a new feature might have more impact than others. But how to choose the right one?
As an exercise to be done in a Workshop with the client, we write down the entire feature set. To start with, it gives us a broader view of what might come next, but the ultimate goal is to get an ROI number for each feature. The higher the ROI, the more imperative a feature is, the higher the priority is.
The ROIReturn On Investment depends on 2 factors: Features Value and Effort.
ROI = Feature Value ÷ Effort
A Feature Value represents the potential added value of a certain feature and the impact it will have on the product.
How to measure a Feature Value depends on each product and on how success and OKR's are measured. For this matter, each of the following items has different levels of importance – a multiplier.
The multiplier can, and should, be changed depending on each product's characteristics.
Each item shall be awarded with a rating from 0 to 5. Each of these ratings must be multiplied by the multiplication factor. The value might range from 0 to 100.
This is an example from a product we've been working on:
- x5 Impact on Conversion – will it increase conversion?;
- x4 Impact on Costs – does it require extra funds?;
- x3 Impact on Customer Engagement – will it drive further engagement?;
- x2 Impact on User Experience – does it improve user experience?;
- x2 Impact on Operations – does it reduce Operational burdens?;
- x2 Impact on Product Competence – Does it make the product more comprehensive?
Effort is a time estimate, typically in days, provided by the Team for a certain feature.
In the end, for this example sake:
ROI = 86 ÷ 20
ROI = 4.3
Is it good? Nobody knows.
An isolated feature ROI is meaningless on its own. Instead, it makes sense when compared to the ROI of other Features.
Now that the next Milestone is defined, the team is ready to assemble a plan on how to breakdown and manage the Project so it can achieve its OKR's within budget, on time.
There's a broader, higher-level planning to be done at this phase:
- Breakdown the Milestone in Epics;
- Assemble the Epics together in a Roadmap considering task dependencies between Team Members;
- Evaluate whether or not Milestones can be met, both time wise and budget wise.
With this, we'll get a wider perception of the Milestone. It will be particularly helpful further down the line, in order to understand whether or not the Team is on track.
Once a Milestone is set, each Epic must be put into a Product Requirements document.
This document is the source of truth and will be carried through the entire process by all participating Team members, from the Designer, all the way to the Developer.
The document can be made up of the following items:
- Briefing – Overall description of the Epic;
- OKR's – Problems to solve, Goals and Metrics;
- Assumptions – Any assumptions that might exist;
- Requirements – Broken down tasks;
- Deliverables – Any approved, final deliverables;
- Questions – Any questions that might exist
On the first instance, it is the Product Owner responsibility to fill in the document where it fits. It's the Product Owner's role to fill in the Summary (Status, ROI and Team), Briefing, OKR's and Assumptions (if any).
Later on, once the Epics are broken down into smaller pieces (more below at Sprint Planning), the Product Owner must fill-in the Requirements table with those Issues and relevant Notes.
Projects and Products have multiple people working on it, Designers, Developers, Illustrators. By keeping the Product Requirements up do date, you are making sure the next team member in the product development chain will have easy access to the work done before them.
At a later stage where each piece of work is being finished, as a Product Owner, you should follow by filling in the Deliverables table.
Keeping the Product Requirements Document up to date at all times is time-consuming on your side as a Product Owner, but will save time to the remainder Team.
As it can be read in How We Work, we work in SprintsA Sprint is a short, time-boxed period of time when the team works to complete a specified amount of work..
They make projects more manageable, as they allow teams to ship high-quality work, faster and more frequently, with the added flexibility of allowing timeframe adjustments.
Because tech products are not set-in-stone (or at least they shouldn't be), there is often the need for change along the process. By following an adaptive methodology and working in Sprints, we can quickly shift the team's focus from one issue to another.
As a successful product is always ongoing, constantly improving by adjusting to its users' needs and feedback. Sprints facilitate this kind of ever-evolving mentality.
Every new Sprint starts with a Sprint Planning meeting. This meeting is a collaborative event where the Product OwnerAt Significa, a Product Owner (PO) is the contact point with the client. The PO is the client's voice at our office. is responsible by ensuring the Team gets briefed and develops a common understanding of the Sprint Objectives and their possible constraints. To avoid unnecessary loss of focus and consequent delays, a detailed Q&AQuestions and Answers may follow.
Together with the PO, the Project Manager and the rest of the team will pick-up from the previously established Epics, break it down in smaller, more manageable issues, create them in the BacklogBacklog is the list of issues that are ready to be worked on., prioritise and assign them to the right Team member.
With this, we ensure that all the pieces fit nicely together and there's no room for miscommunication or misunderstanding between the Team and the client.
- Breakdown the Epics in smaller issues;
- Prioritise issues;
- Assign the issue to the correct team member;
- Understand how success will be measured;
- Create a plan that gets shared with the client.
No matter the planning, no matter how much the Team tried to predict hypothetical bumps, there will be blockers, problems and difficulties along the process.
In order to keep the entire Team up-to-date with everyone else's progress, but mostly to solve potential friction points and blocker, we do two different kinds of recurring meetings:
- Stand-ups: a daily, 5 minutes, informal meeting to solve blockers;
- Mid-sprint Review: done on Friday, a Sprint status update to measure progress;
We're not micro-managing people, but instead we're trying to make their job easier by anticipating problems and getting them figured out beforehand.
- Develop a common understanding of the Sprint progress;
- Work together on solving blockers.
- A clear path to keep woking peacefully.
Every sprint terminates with a Sprint Closing meeting. The whole Team sits together and debriefs the soon-to-be closed Sprint by addressing a couple of meetings:
First, in a Sprint Review meeting, the Team demonstrates what they’ve accomplished over the Sprint. It's also the opportunity to showcase their work to the PO and their teammates before it moves on to the next in line, or to the client itself.
Second, we round out the Sprint cycle with a different meeting: The Sprint Retrospective. This is the Team's chance to identify areas of improvement for the next Sprint. Not only is the product continuously improved, but the people are too.
- Showcase work done during the Sprint;
- Measure sprint progress and task completion;
- Evaluate how the next Sprint can be improved;
- Make sure Deliverables are ready to be shared;
- Close the sprint.
At the end of every Sprint, the Project Manager compiles a document with a few Sprint related details. Even though we keep communication tight and, most likely, the Client is on pair with the progress, the Sprint Report aims to formally mark the end of a Sprint.
Such report includes the following information:
- Sprint Summary: Start date, End date, Status, Team Members, Project Manager, Product Owner and Stakeholder.
- Last Sprint Report: a Sprint overview with relevant details;
2.1. Completed tasks: List of completed issues;
2.2. Uncompleted tasks: List of uncompleted issues;
2.3. Resource Allocation: Whoever was involved in the Sprint;
- Next Sprint Plan: An overview of the next Sprint and its relevant notes;
3.1. Tasks Planned: Tasks to be done;
3.2. Resource Allocation: Whoever will be involved in the Sprint.
- Roadmap Overview: A big-picture view of the Roadmap and where we stand;
4.1. Roadmap Status: On Time or Delayed, and why it happened.
Bugs and Fixes
We have a thorough internal QA process which we make use to minimize delays and potencial problems.
Despite that fact, new bugs will be found in Staging and Production environments, as we, the Clients or the Users keep using the Product.
As these new issues come along, people tend to stress out about them. However, before messing the ongoing sprintWe praise peace of mind and letting the Team doing their work while 100% focused. For this, we avoid interrupting their Sprint and shifting the Team efforts to something else, it takes careful evaluation of such bugs.
For this matter, and in order to prioritise those bugs based on their urgency we make use of a bug triage framework. This pattern makes it clear to define which bugs must be Fixed Immediately, should be Fixed Next Sprint or should go to the Backlog.
The graph relies on 2 axis, being Y the seriousness of the Bug and X the % of affected users. When both are put together, depending on where the Bug sits, the priority is self-defined:
After such exercise, each bug get tagged with one-out-of three labels:
Urgent – To be fixed right away. It must be included in the current Sprint.
Medium – To be fixed in the next Sprint. Not worth including in the current Sprint;
Low – To wait for spare time while sitting in the Backlog;
Bugs can be reported by anyone but when addressed by the client or by one of the Team Members we can speed up the scanning and reproducing time by filling in a Bug Report Document. The sole purpose of this document is to get all bugs centralised in one common source of truth.
The document is made of a table with the following parameters:
- Bug Found;
- Description – ideally with image or video;
- Steps to replicate;
- Issue – Once it makes the issue Backlog;
Once a bug is chosen to be fixed, it gets created in the Backlog. Then it other stays there or makes the Sprint based on its priority.