Senior Product Manager, eBay (2016–Present)
Structured Data is in charge of productizing all data across eBay, to power product-based experiences which empower both sellers and buyers, driving every online and offline eBay experience with profound business, legal and UX impact.
-
Leading 12 cross-domain teams as part of eBay's Product Based Shopping Experience to revolutionise shopping and selling experiences across all eBay, with substantial uplift to seller completion and buyer conversion rates (initial results from early access release).
-
Leading eBay strategy and R&D for resolving product duplications in the catalog, marked as the top quality issue of Structured Data. In charge of research, development and analytics teams. Achieved 70% reduction in data corruption (surpassing yearly goal of 60%).
-
Successfully integrated two remote R&D teams into the ongoing dev process, including transition to Agile methodology, defining goals and success metrics, creating a roadmap and integrating into existing management infrastructure.
-
Leading a fully data-driven EOL process for a legacy system due to lack of direct access to users.
Asaf Bord Product Manager
Finalizing Your Quarterly Plan
Part II - Plan your work through the quarter and communicate
How can we make sure we are not over committing specific resources in the team?
And what do we need to make sure makes it to the next sprint?
After reviewing the first 4 steps in building your quarterly release plan, in Part I, we now turn to do some more Project Management work, necessary and more often than not, insightful to a degree which could change your quarterly commitments; and finally communicating and closing down your commitments.
5 - Plan Your Execution Throughout the Quarter
-
The last step is to create a fairly standard gantt chart, by allocating each user story to a specific sprint.
-
The point of this stage is to act as a sanity test for your plan. It will allow you to address some of the following considerations, which don't surface in the previous step, and can greatly impact your plan. These are:
-
Deadlines
-
Risks and priorities - you will want to start with the top epics, and those with highest execution risk
-
Dependencies between epics and user stories
-
Dependencies on external resources - such as integrations with other systems, user availability for UATs, company-wide release cycles, etc.
-
Availability of critical internal resources - both their work and personal schedules
-
Maturity level of PRDs and epic readiness for development
-
-
Since we haven't yet stressed having user story small enough to fit in a single sprint (as we should eventually), it is OK to spread out a large line item over several sprints.
-
As you go into your quarter, you may choose to keep working with your gantt, by updating more granular user stories, estimations and release schedules, or you may choose to only come back to it when there are major changes to the original plan. Both approaches are fine!
-
Row 4 sums the total number of story points allocated per sprint, and highlights sprints which are at capacity (zero bugger) in orange, or over committed in red. You should avoid planning sprints for full capacity, and always make sure never to have sprints which are over committed.
-
You may find that some constraints actually prevent you from executing the plan as intended (e.g. two epics must be deployed at the same time and cannot be staggered - you may only be able to commit to one of them, and push the deadline for the other).
-
Is you last sprint empty? This means you did you job well, and provided the team with enough buffer to manage unexpected work and complications. If hell happens to freeze over and everything went according to plan, you can pull something from the Q2-20 column into the last sprint.
6 - Communicate
-
Regardless of what format and cadence you communicate your plan in, you now have a clear way to explain your choices and tradeoffs. I have found that using this method there were much fewer questions and pushbacks to our plan, and we were able to conduct them with far greater confidence.
-
Share your plan with your team and partners:
-
Make sure to only share the overall commitment, and not the detailed sprint-by-sprint version. The detailed version is only used to validate some execution considerations, they should not be perceived as delivery dates.
-
Validate your assumptions and get feedback. You will be surprised how often new constraints are identified once people are presented with a clear visual of their plan.
-
-
As you inevitably receive fine tuning and pushbacks from stakeholders and managers, you will have a structured way of identifying and communicating tradeoffs. By taking each new request through the steps above, you will be able to suggest which epics should be removed, or reduced scope, in order to accommodate the change. This is true both priori to committing, and throughout the quarter.
-
Final Tips
-
Add a section for engineering initiatives, tech debt and support. Even if you simply time-box it, it will make everyone comfortable knowing that this time was accounted for, is being managed, and won't immediately eat into your buffer time.
-
If you chose to follow step 5, you should update your gantt after you properly break down your epics into small enough USs.
-
You can add hyperlinks to the epics and USs in JIRA (or any other management platform you use). The downside, however, is that GSheet do not automatically sync with JIRA.
-
Start each sprint planning by reviewing your quarterly plan. If you manage it properly, sprint planning should be as simple as validating we are still on track, and pulling the right USs from the backlog. You may even want to pre-create all sprints in JIRA with all USs already allocated (albeit perhaps still empty).
-
If your company practices annual planning, I feel for you... Without going through all the problems of an annual release plan (note PLAN, and not ROADMAP - your roadmap should definitely be more forward looking than a single quarter!), suffice to say that going through the above for a full year in advance will be a waste of your time. My suggestion is to do this only for the next quarter, and leave the rest of the year in high level, while clearly communicating uncertainty and risks for anything beyond.
This tool is easily extendable to support multi-team planning.
Finally, here's how a fully flushed quarterly plan may look like:
