In an earlier blog post, we compared the WBS Dictionary to the Agile Definition of Done. However, we never reviewed any connection between conventional project management Work Breakdown Structure (WBS) and the decomposition of the product backlog to produce the sprint backlog. Before we can describe what completion of the item looks like, we must first […]
This may or may not be a true story, but I promise it happens every year. We start with the customer organization and a supplier that the customer refers to as a partner supplier. This “partner” supplier collaborates with the customer to develop custom components for a larger system the customer sells to their customers. […]
Requirements and Benchmarking One of the things we can do to understand and develop our own requirements is to explore other products that are similar to our proposed product or that solve the same or similar customer problem. Where there are similar needs met, benchmarking is a way for us to understand how other suppliers have […]
I was thinking about technical debt in the context of our recent spate of requirements postings on the blog. Technical debt, from my perspective, does not just apply to software. We incur technical debt when we implement an easy solution in the short run, as opposed to the best overall solution. In other words, we […]
This question was posed by Tom Cagley on Twitter. At first blush these may seem at odds or exclusionary, but perhaps not. I know why it may seem difficult to be innovative while we are hyper-focused on continuous improvement activities. A company that focuses on continuous improvement that tends to be incremental can occlude […]
This blog post originates from Capers Jones LinkedIn comments about toxic requirements. He posted a comment to a requirements article and brought up bloated requirements and toxic requirements. I have never heard of the name “toxic requirements” perhaps that is uniquely Capers Jones identifier – I like it. However, I believe I have experienced toxic […]
I have never worked on a project that took that approach. In my embedded product development experience, the requirements grow as the product iterations are delivered, evaluated and tested. The results of those evaluations and tests will impact the requirements. There will be additions, subtractions, and alterations of the requirements. We will update the requirements documents, […]
Our project must balance the input from a myriad of people that are associated and contribute to the project, along with those funding the project to be successful. To be able to do this, we will need to understand our stakeholders and their perspective. Some of our the stakeholders will add requirements, support existing […]
We take a break from our requirements management run for this blog. I was talking to an executive about some training for his organization. He wanted the training to focus on action, on doing (he, in fact, said do, do, do). He emphasized this very clearly and repeatedly, the action portion of continuous improvement. This […]
Requirements Language As we collect requirements we are going to need to perform some sort of evaluation. We know the attributes of good requirements, now we will compare those attributes against the documented requirements. However, we will not stop our evaluation at the type of language. We will extend this evaluation to other areas that […]