A Step-By-Step Production Process
As you probably know, most of the time spent on product development is in the production phase. It’s where all of the hard work from discovery and planning starts to take shape. You can learn more about the previous phases that got us here in our approach to digital product management blog post.
Once we are in production the agile methodology takes over. Agile and scrum are incredibly valuable tools that support maximizing teams effectiveness. However, it takes a different strategy to deal with constraints like budgets and deadlines. When you research the agile methodologies you will find that they avoid discussing constraints in favor of a user’s experience. This is a fantastic philosophy but in the business world, time and money are real constraints that require consideration.
Our step-by-step process assumes that you are familiar with the agile methodology and SCRUM. There are many resources to learn about these concepts and we aren’t going to cover them here. We should also mention that the 70/30 method is meant to be used in an agile workflow. Typically, for digital product development and custom web development. For more information about which methodology you should use (and when) checkout out our post about when to use the agile methodology and when to use other project management methods.
Step 1: Groom Your Backlog
Your backlog is built when you are creating your roadmap and should only include real work, meaning actionable tickets. All of the user stories are defined and estimated. Each user story sorted in the order of priority. We like to focus on crucial user journey tasks first. Then we prioritize features with the lowest effort and highest business value. When you’re done, your backlog should look beautiful like the image below.
Step 2: Plan Your Sprints
Let’s assume your sprint velocity is 20 points. At the beginning of each sprint, we will pull in the next 20 highest priority points. Those 20 points represent 70% of the time of the sprint. Each sprint should include 70% of the time for feature development and 30% for product hardening (making your product more stable). Only pull in 30% of the sprint worth of bugs. Some sprints have more bugs than others and they should go into the top of the backlog and pulled in later. You want to stick to the system.
Step 3: Execute Your Sprint Plan (Work & QA)
At this point, you are in an active sprint. Remember, you are going to use 30% of the time in the active sprint to put towards product hardening. These are the tickets created as a result of previous QA efforts. Product hardening tasks are completed first. After they are addressed, we move to the features, this ensures that the work we just did is still fresh in our mind. Any bugs found in the current sprint for active stories should take priority and completed before the sprint ends. Fixing as many issues as possible in real time will help create stability in your product.
Step 4: Plan Your Next Sprint & Repeat
Any tickets that weren’t completed in the sprint should move to the top of the backlog and the active sprint should close. Like we mentioned above, based on your velocity you should pull in the next bundle of stories (70%) and the bugs logged from the previous sprint (30%) and start the process over again.
Step 5: Check-In and Negotiate
Change is inevitable, things come up along the way and priorities change. This system is perfect for that. If a scope change takes place, the question becomes, how many points is the change worth? We should also ask, which other stories no longer relevant? Taking on more points without adjusting time or budget doesn’t always work unless the project is under budget. The beauty of negotiating story points is that features are pulled out to keep the project on track and marked for a future phase of the product. The backlog should ALWAYS support reality. Any tickets that are outdated or obsolete are updated or deleted.
At Solid Digital, all product development is run this way. Using the 70/30 rule for project planning has removed the need for alpha phases in our projects and decreased time and cost during our beta phases. When a project is managed transparently and teams can openly negotiate story points, everyone wins.
