Step up your IT game and get inspired by Jimmy's Agile Framework for product owners. Transparency is our core value, so we decided to share our Scrum-based step-by-step workflow with the whole world. Why? Because every line of code that ends up in the trashcan is a wasted opportunity. So if you are a rookie PO or want to try efficient practices, feel free to apply our methods and let us know how they worked out for you!
Every step has been time-tested and proved efficient both in startup and enterprise environments. Make sure you follow us here on Medium, so you don't miss other parts of our PO guide series. Let's get into it.
As a Product Owner, you can join a project in different stages. Often you don't join the project on day one, but you have to hop on a moving train with documents and outlines already set up. You must quickly catch up and prepare the playground for development.
These tips will help you get started:
1) Get the keys to essentials like Jira, Gsuite, Slack, and other tools
2) Become a product expert. PO must know everything about the product and pass vision and requirements clearly to the dev team. Familiarize yourself ASAP with the project's vision, business and product strategy, key stakeholders, etc. If these necessities haven't been outlined, prepare them. When a team member asks you about the roadmap or product's goals, you are the one who should know the answer.
What PO must know:
3) Begin from the top and dive deeper into the product's and business' needs. Vision and strategy should always transform into high-level requirements. When you know the basics, start preparing your workflow:
*Note: Every project is different. For product managers, it's more common to analyze priorities and milestones and adjust the workflow to meet them, but occasionally, PO might be responsible for even creating them.
4) Get main stakeholders in the same boat. This is where many product owners fail due to insufficient communication. The thing is that a lot of clients don't necessarily know the role of a PO, and the function can differ across companies, so it's your job as a PO to understand expectations linked to your position. When we deliver the team that includes the product owner, we always explain his responsibilities and competence in advance. A PO that is not in frequent and regular contact with stakeholders is not a good PO.
What to do:
5) Be proactive and don't leave anyone guessing in the dark. At Jimmy's, we believe in radical transparency and create a safe space where any feedback and questions are welcomed. You should do the same. People often don't want to admit they don't know something or are afraid to ask. It's your job to reach out and clarify things actively. We always tell our people: "You are a senior and highly skilled professional and clients, projects and Jimmy expects your feedback and insights and it will be more than welcome.
6) Create user stories, at last! Make sure to connect each user story to high-level requirements. We'll discuss user stories in-depth in the upcoming article.
7) Find your workflow. Each PO has its own approach to getting things done, and it can vary significantly based on the project. Take our hints but don't be afraid to come up with your own:
8) Demand transparency – you try to be as transparent as possible, and so should others. As a PO, you need to know what others are up to. Lack of inter-team communication leads to failures. Make sure that you get answers to these questions:
Pillars of Jimmy's workflow
Throughout our careers, we have already had countless opportunities to test out different approaches and processes. These are the pillars that proved themselves worthy and help our teams and Product Owners thrive:
• Strong, open, and continuous communication in the team
▹ Communication and planning between FE & BE & QA
▹ Collaborate on 1 user story together as a team – sync regularly and don't skip the cross- functional feedback loop
• Don't start a new user story before you finish the previous one – keep your focus and don't switch. When you don't finish a user story in one sprint, do it in the next one. Don't switch to anything else, because if you do, in the end, you'll have no testable increments, just a lot of unfinished work.
• Define a clear sprint goal so that the team has a clear vision
• Control the outputs by setting milestones
▹ The team will be motivated and result-driven
▹ You'll avoid misunderstanding with user story details and be ready for the next sprint
• Don't let the work-in-progress skyrocket
• Have at least one pull-request per day for each team member
I hope this guide helps you onboard projects successfully and catch up as soon as possible. In the next part of this series, we'll dive into user stories, show you common mistakes, and add a few tips on writing crispy user stories everyone will understand.
Reach out to get more information.