Not all television is not mind numbing. I enjoy The History Channel and many other similar channels as these are not exactly learning opportunities but close. However, my son turned us on to a show called House on Netflix[1] and it is very interesting. House (also called House, M.D.) is an American television medical drama that […]
From what I have learned over my life thus far, is that we need not think of things as either-or, at least not all of the time. Heavy metal guitar player’s use pick slides to make interesting screeching sounds, but bass players can also use this contrivance – to make a different yet similar if […]
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 […]
I was exploring twitter as I sometimes do in the morning when I came upon this interesting post. It is true, to paraphrase Rudyard Kipling, waterfall is waterfall and agile is agile, and never the twain shall meet[1]. So? The goal of any project is to successfully deliver the objectives of that project and […]
There are a number of factors that can influence the approach we take to managing the requirements. I provide a brief list below (this is not an exhaustive list): the technical sophistication of the product the risk associated with a mistake distribution of the team The more technically complicated the product the more diligent our […]
State diagrams can also help us develop the requirements and consider software and hardware requirements that may not be so easily evoked from the customer. The state diagram describes the behavior or the software / system, specifically the number of states in which the product may be. There will be transitions between states defined by […]
Scope, Requirements, and Work Breakdown Structure The scope of the work and the requirements provide us with information from which we can build the Work Breakdown Structure or WBS. In fact, even before we are able to start doing the work to build the expected results of the project, our work breakdown structure should capture […]
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 […]
The customer can seldom articulate the technical details of the product. The customer may define the product or need in terms of function and performance, but building the product from these documents will be extremely difficult or perhaps impossible. We will need some type of document to begin describing in technical terms the product that […]
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 […]