Managing Feature Requests & Backlog
Download as PPTX, PDF2 likes531 views
The document discusses managing feature requests and backlogs in web application development, emphasizing the importance of a structured feedback loop and prioritization strategies. It outlines a five-step process for handling customer feedback, which includes asking for feedback, triaging requests, cleaning up feature ideas, assessing their value, and developing the selected features. The author shares insights on maintaining efficient release boards and emphasizes the significance of communication with stakeholders throughout the feature development process.
Managing Feature Requests & Backlog
- 1. Managing Feature Requests & Backlog Jamie Thomas Co-Founder - Cognito Forms
- 2. Know Your Audience Do you manage feature requests? Are your stakeholders internal or external? Do you have more things to work on than time? Do you need better ways to prioritize your work?
- 3. Know Your Presenter I’ve been building web applications for twenty years. I lead a team of 25 amazing web developers and designers right here in Columbia, SC. I write or review code and designs every day. My passion is building stuff.
- 5. Customers In 149 Countries
- 6. Minimum Viable Product When we launched Cognito Forms, it had an amazing form building experience and let you build, publish and manage entries, but not much else.
- 7. Managing Feature Requests 2. Triage 3. Cleanup 4. Review & Assess 5. Develop & Promote 1. Ask For Feedback 5 steps to controlling the chaos of customer feature requests Feedback Loop
- 8. Step 1: Ask For Feedback We started by creating a Trello board with a list of our own ideas for essential missing features
- 10. Be Prepared to Listen As you can see, More Features = More Feature Requests 0 50 100 150 200 250 300 350 400 Customer Feedback
- 11. Never Be Afraid to Ask We even asked for feedback on our “plans” for “paid plans”. While we did not get as many up-votes for this feature as others, we received 29 detailed comments that significantly shaped our plans before release!
- 12. Step 2: Triage 50% of “bugs” are really “how to” questions 50% of “feature requests” are really “how to” questions 50% of “how to” questions end up being “bugs” or “feature requests” Not all feature requests are feature requests. Bugs How To Feature Requests
- 13. Track Good Ideas Triage incoming feedback to find new unique merit-worthy suggestions or refinements to existing ideas. Then add the idea to the board and ask your customers to up-vote their own great idea.
- 14. Step 3: Cleanup Just like a kid’s messy room, sometimes you have to step back and put things in their place. A shelf full of disorganized feature requests is no different.
- 15. Consolidate & Refine Do not delete duplicate features, merge them to make them better. Step back a bit and see how smaller ideas can be combined into requirements for a larger feature. Group features into logical areas and be concise with titles to facilitate scanning.
- 16. Step 4: Review & Assess At some point, you must decide what to do next. Choose wisely, because the more features you choose, the less you will accomplish. Always engage the product development team in the selection process
- 17. Step 5: Develop & Promote Identify a limited number of features to promote to In Progress. Work on as little as possible Note the lack of scroll bars Release as often as possible
- 18. Track Your Progress Remember that what you have already done is much more important than what you have not done. Features that are in production are much more valuable to your customers than ideas. Seeing what you have accomplished explains why you have not gotten around to the rest.
- 19. Communicate Why bother releasing a feature if no one knows about it! Tell your customers, throw a party, bring out the band, shout it from the rooftops! Blog posts are an excellent forum for promoting the value of a new feature.
- 20. Communicate While you may build features to attract new customers, you existing customers are still your primary audience. Let them quickly know, within you product, that new features are available, and how to use them! In-app messages quickly alert your customers—just don’t be annoying with them.
- 21. Communicate Email is still a great way to communicate. Of course you can promote on social media as well, but a personalized email with simple “calls to action” and the opportunity to just reply to provide feedback is very powerful. Email is still relevant. Let your customers know about new features, and Ask For Feedback again!
- 22. Fluffy Puppy? Thus ends the fluffy feel-good portion of this presentation. Managing high-level marketable features is fun, but it is also just the beginning.
- 23. Managing Releases A few big ideas require thousands of small decisions. Avoid getting lost in the details, but make sure you know the details. Feature Boards Release Boards 1. Backlog 2. Hotfixes 3. Feature Releases
- 24. 1. Backlog Where everything goes to die…
- 25. Deliberate Triage Internal ideas, bugs, tiny feature requests, and random thoughts all get sent to triage. The team reviews these once a week and promotes them to release boards or relegates them to backlog. Nothing can be left in triage—promote or die. In the heat of battle, don’t think to too hard—just create the card and send it to triage. Backlog Hotfixes Feature Release
- 26. Ignore Backlog If it is important, it will come up again. If the feature is critical for your stakeholders, they will keep letting you know. Bugs are features too— your support load will let you know what is important. But don’t forget to search your backlog before adding new stuff.
- 27. 2. Hotfixes If you release perfect software, you took too long making it perfect! Avoid technology debt by releasing early and often, but be prepared to work quickly to resolve issues.
- 28. Hotfix Drivers In between feature releases, there are invariably surprises that affect enough customers to make them important. Hotfixes are largely driven by issues reported by customers through support, as well as proactive diagnostic monitoring of errors and performance. Triage Support Diagnostics
- 29. Release Workflow Critical issues get promoted to In Progress. As developers and designers check in fixes, they promote cards to Ready for Testing. Staging deployments automatically promote cards to Testing. Cards then cycle through Failed Testing or become Ready For Release. In Progress Ready For Testing Failed Testing Ready For Release Testing
- 30. Test Cases During development, feature cards have requirements. Cards promoted to Testing must have Test Cases. Failures during testing get recorded similarly. Once all Test Cases and Failures are resolved, cards are promoted to Ready For Release.
- 31. Release Archiving When hotfixes role out to production, the entire Ready For Release lane moves to the Release Archive board. This effectively clears out the Production board, except for some potential lingering In Progress items. Release boards should be both clean and temporary.
- 32. 3. Feature Releases Where the rubber meets the road. If you do not manage this process correctly you either fail to release or wish you hadn’t.
- 33. Release Boards Are Transient For each release we: 1. Create a brand-spanking new release board, which is green because it is going places. 2. Fork our product to prevent overlap with hotfixes and the occasional parallel feature development. 3. Put as few features as possible on the board, and then beef them up with requirements. You must know when you are done! Avoid adding stuff along the way, or you will find yourself on a treadmill, going nowhere fast.
- 34. Track Progress Include enough detail in your release management process to ensure you know when you have finished implementing a feature. Avoid adding requirements to a feature. Consider removing requirements to are not essential to the feature release.
- 35. Test & Release!!! Similar to hotfixes, promote and test until everything is Ready For Release. Then do not be afraid to pull the trigger and release your labor of love to be embraced by your customers! Finally, archive your release board and start over with a clean slate. 1. Create Feature Release From Ideas 4. Archive Everything 3. Deploy to Production 2. Build & Test 5. Repeat
- 36. Recap 1. Transparently engage with your stakeholders. 2. Release early and often. 3. Ignore backlog and stay focused. 4. Find a process that works for your team.
- 37. Questions? Always remember that product development is a race. • You must push yourself to be competitive. • You must pace yourself to not burn out. • You are on a track, going in circles—start and finish lines are arbitrary.
- 38. Converge Feedback Provide feedback about your experience at ConvergeSE and register to win an Apple Watch! convergese.com/feedback
- 39. A Better Form Builder Built by web people for web people. cognitoforms.com
Editor's Notes
- #2: Good Afternoon I am Jamie Thomas and I am cofounder of Cognito Forms, a cloud startup based right here in Columbia SC that is rethinking how to allow anyone to easily create powerful responsive beautiful forms that can actually solve complex real-world problems without compromises. I am going to discuss with you today how we transparently manage feature requests and backlog in a way that engages our customers in a meaningful way and while still allowing our relatively small team to iterate and innovate to get stuff done.
- #3: Since this talk will be about understanding stakeholder needs and prioritizing what is important, I want to first start by understanding my stakeholders in the room—you! Answer each of the following questions by raising your hand. If you did not raise you hand then this talk likely is not for you. If you did, then I will try to tailor the presentation to match my audience—wish me luck!
- #4: I still have my “Teach Yourself Web Publishing with HTML 3.2 in 14 Days” book by Laura Lemay, which is one of the few tech books I can say I have read cover to cover. Google search did not work very well back then…
- #5: Since many of my examples today will be based on Cognito Forms, here is what you will see when to venture over to our product. The key point here is that anyone can try out our product without signing up, and anyone can start building and using unlimited forms for free. This means that we have a lot of people using our service with a wide variety of backgrounds, specific needs, languages, preferences, etc., and not all of them will become paid customers and most of them will not be web designers or developers. We just released our paid plans yesterday morning (whew!), but we already had thousands of customers paying a percentage fee to use our Stripe-connected payment forms.
- #7: Our goal was to release early, before we were really ready to charge for our forms, and listen to our customers to shape the product. For example, just taking a quick glance at our feature page, 13 of 19 of the features we highlight were not available when we launched at the end of 2013. Our first goal was to get users to listen to, then figure out how to listen to them and manage expectations.
- #9: From the beginning, we wanted to try a different approach to managing feature requests. We knew we wanted a transparent way for our customers to know what we were working on and collaborate with us on shaping the product. We were also avid fans of Trello and used this product extensively for lightweight project tracking. We decided, even before we launched, to make our proposed feature list public, similar to how the Trello team itself maintains a public feature board
- #14: Not all feature requests make sense, but most are reasonable. If an idea is similar to an existing idea, try to combine as much as possible. Whether the idea is new or existing, we always share a link to relevant features on our board and ask our customers to up-vote and comment to help us understand what they are looking for. Many of our customers subscribe to our board or just their specific ideas so they can be notified when work on them.
- #16: Small ideas just become requirements of larger features. Good (marketable) features have good titles because they can be easily and succinctly described. Grouping (in this case using color labels in Trello) makes it easy to see impact areas.
- #17: Our customer suggested ideas flow into a general list. Members of our product development team, including developers, designers, testers, infrastructure and support features by sponsoring them. Sponsored ideas have more “meet” to them, and the sponsor acts as an advocate during team planning meetings. After hearing pleas from sponsors and reviewing customer feedback on what’s important, the best features move into “Next Up”
- #23: This concludes the Fluffy Puppy portion of the presentation. Before we begin discussing backlog and release management, do you have any questions or insights from your own experience?
- #24: We’ve covered the tip of the iceberg, the big picture Idea Board. Now we can get into the nitty-gritty of release management by discussing backlog management, hotfixes, and feature releases.
- #25: In addition to our public Idea Board for big picture end user features, we have an internal board just for managing backlog.