[null, {"document_url": "https://deepakalur.wordpress.com/category/software-development/", "unformatted_src": "https://i1.wp.com/farm3.staticflickr.com/2779/4289782818_a19dd14312.jpg", "src": "https://i1.wp.com/farm3.staticflickr.com/2779/4289782818_a19dd14312.jpg", "formatted_filename": "a dd", "alt_text": "Lego", "rendered_width": 350, "rendered_height": 263}, null, null, {"document_url": "https://deepakalur.wordpress.com/category/software-development/", "unformatted_src": "https://i1.wp.com/farm7.staticflickr.com/6070/6086128018_8988c6f562_n.jpg", "src": "https://i1.wp.com/farm7.staticflickr.com/6070/6086128018_8988c6f562_n.jpg", "formatted_filename": "c f n", "alt_text": "Teamwork", "rendered_width": 320, "rendered_height": 320}, null]




In continuing with the previous blog on engineering methodology, I wanted to talk a bit more about how to work the requirements funneling and release management process.

One of the challenging aspects of building a product is to figure out which requirements make sense and which don’t and keep the features in line with the product’s goal and philosophy. This gets compounded by what is pushed by sales (if the product had this, i can close a huge deal deal right now!), inspired ideas from visionaries in your team (build it and they will come), your own insights based on the product and customer knowledge (many customers have asked for this), and a myriad of other things.

One approach to manage this is to use a Theme based development stream. A theme basically focuses on one or two large related areas of need in the product. Getting different stakeholders to agree on a theme is much easier than to get them to agree on individual requirement priorities of disparate items. These themes become the place holders and guidance for directing an incoming requirement. And the themes can then be mapped out in terms of relative priority and lined up for the release milestones. Aim for the theme to be delivered in less than 3 months, and each feature in the theme should be done in sprints of no more than 3 weeks. The themes are flexible. You may have to add or remove features to the themes at any given time. However, if a feature is already in development, most often, it is too late to remove it from the theme. In quicker releases, you might map a single theme to a release to keep the scope down. In larger releases, related themes may have to be released together, but be careful about combining more than 3 themes into a single release. Once you have the themes in your pipeline, you can then sequence these themes into milestone releases. In my experience, this approach allows efficient and effective allocation team members to complete the features and also allow them to work on multiple themes. This way, the entire team can be busy working on delivering one or more themes, and therefore, one or more releases.

Themes also make it easy for your marketing and sales teams to articulate the value of the next release to current customers. Instead of digging out the nuggets to sell/promote from a large list of features listed for each release, you end up having upfront agreement on what the next release is going to be all about. So while the engineering team is working on development activities, marketing and sales teams can work in tandem on collaterals, outreach and other launch related activities. This allows for closer collaboration and more efficient cross-team work to achieve a successful release every time.