From time to time, you’ll have many projects on the go, and members from other teams or even stakeholders will look at your backlog. Make sure that you put together half a sentence for an epic/feature title. Going forward, I’ll explain how I structure my epics. I Always Create the Epic First in my Backlog Let’s look at a past project that I’ll simplify. Note: You can’t always apply all points to a story due to complexity, cross-team dependencies, etc. I follow the INVEST guidelines (defined by Bill Wake) when I write stories which means they are: The goal is to iterate in smaller increments and deliver software and value in smaller chunks. Instead of working on the whole big feature, you break it down into smaller pieces. Stories are a breakdown of the bigger scope of an epic. The User Stories for Your Backlog and Sprints □Ī user story (short: story) is a collection of requirements that are detailed enough for Software Engineers to implement. If a feature is very clear, like a change due to legal requirements, I make the epic as detailed and precise as possible.Ģ. The epic helps my team to understand the goal and together we work out how we can get there. I prefer this over dictating solutions through one (product) person. Open-formulated features are beneficial because the whole organization, especially the Design and Engineering departments, can think about a solution. In most cases, I try to cover high-level goals (not detailed solutions) to reflect the (business) value. I use an epic to collect all relevant information related to the project/topic. You can link all other issues to the epic to keep track of every task that’s related to a project. We can call it a feature, a bigger project, an initiative, or just an issue that collects the work of mutual areas. The Epic is the Umbrella of User Stories ☂️ In the following section, I’ll refer to Jira but you can apply everything to other tools or even a physical board.ġ. In most of my previous companies, the Product and Engineering departments used the project management and issue-tracking tool Jira. Let’s look at two basic issue types and how to start preparing a project with them. One key takeaway for me is the better I structure myself, the better I’ll structure my backlog. However, I have learned that while preparing and planning a project the questions you need to answer related to issue types are simpler. That doesn’t mean I’m the only one who answers these questions within a squad. And that’s fine because it’s part of the job. These are only some of the questions I’ve answered over time. “Is it a bug or a feature?” “Do we need a user story or a task?” “Should we do some research and create spikes?” “Wait, is that tech debt?” “Should we create a follow-up deployment task?” “Is this an epic or a story?” I’ll describe a basic structure you can use as well as a couple of examples and mistakes I’ve made to help you start off better than I did back then. I’d like to share some simple steps on how to set up your product backlog and PBIs so you can build awesome products. After many sprints and projects, I came to the conclusion that it’s most important that:Įveryone knows what the priorities are, and commits to building a great product □Īs Product Manager, you’ll drive the backlog activities and its items, called product backlog items or PBIs. I’ve managed 12 different team backlogs over the course of 7 years as PM, as well as multiple backlogs in my job as a Product Coach. It's not something I spend a lot of time dwelling on. There are different opinions about who “owns” the backlog (the Product Manager or the whole squad). It is the single source of requirements for any changes to be made to the product…” ( Link to source ) “…the Product Backlog is an ordered list of everything that is known to be needed in the product. Let’s have a look at the definition of a backlog: I want to share how I started and what lessons I learned with user stories and epics that help me manage my backlog today. If you felt or feel the same, I recommend you continue reading. I was completely overwhelmed and didn’t know what to do. I saw a lot of lines with cryptic titles, ticket numbers, and different colors. It feels like yesterday when I first sat in front of my product backlog.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |