How good are our estimates? We can use PERT to estimate the time it will take to implement each requirement. We can use timeboxes to schedule the requirements within each release. If we don’t know how good our estimates are, its an exercise in futility. Scheduling is about more than predicting the future, its about knowing how much faith to have in our predictions.
Communication / Consulting / Product Management / Requirements / Software development / Testing / Use Cases
Posted on:
Communicate Relevant Quality Metrics
Most teams think about testing in terms of code coverage – what % of the lines of code are covered? What matters to our stakeholders is how well the software works. More precisely, how well does the software let the users work? We should be targeting our quality message in terms of use cases, because that matches their perspective and context.
Marketing / Software development / Test Automation / Testing
Posted on:
Market Segmentation or Senseless Mistake?
A grass roots campaign has been started by Peter Provost to get Microsoft to include unit testing support included with all versions of Visual Studio 2005 (VS). Currently, Microsoft is only including it with Visual Studio Team System (VSTS) versions of VS. This looks to be a great example of a killer feature in a product providing so much surprise and delight that people are demanding that it be universally available. This is also a great example of market segmentation by Microsoft. The irony is that there is an open source alternative that makes the opportunity cost very low, and yet people are still clamoring. Let’s see why.
Agile / Process Improvement / Software development
Posted on:
Getting agile – should we?
Should we adopt an agile process for our team? Methods and Tools has posted a two part article titled Adopting an Agile Method. In thier article, they explore five areas of consideration. We provide our thoughts on each area. Five areas to consider (from the article) Our organization’s culture Our […]
Agile / Interaction design / Process Improvement / Product Management / Requirements / Requirements management software / Software development / Use Cases / UX
Posted on:
Gartner research on Agile Requirements Definition and Management (RDM)
Gartner has a research report available for $95, titled Agile Requirements Definition and Management Will Benefit Application Development (report #G00126310 Apr 2005). The report is 7 pages long and makes an interesting read. Gartner makes a set of predictions for 2009 about requirements definition and management (RDM) systems, and the software created with RDM tools. Gartner misattributes several benefits of good process to RDM tools. We give them a 3.5/7 for their analysis – check out the details here.
Agile / Process Improvement / ROI / Software development
Posted on:
Two big benefits of incremental delivery
Tarun Upadhyay wrote a fair criticism of our previous post on why incremental delivery is good on his blog today. It is great that he is extending the conversation, and he makes some valid points. We definitely missed a big benefit of incremental delivery, and will cover it in this post.
Interaction design / Requirements / Requirements management software / Software development / UX
Posted on:
Persona Grata
Different people approach the same goal very differently. When we don’t truly identify our users, we end up with software that dehumanizes, waters-down, and otherwise fails to succeed at anything more than grudgingly tolerated functionality. Even worse, we may ignore the needs of our key demographic, resulting in software failure. When we use personas instead of generic use cases, we can avoid both the misery of a failed product and mediocrity of marginal success.
Product Management / Requirements / Software development
Posted on:
Goldilocks and the Three Products
Michael on High-Tech Product Management and Marketing has a fantastic “wish I wrote that” post about the importance of having the right number of features. He has several references, the best of which is Kathy Sierra’s Featuritis vs. the Happy User Peak post from June 2005. The two posts combined provide great insight into why having too many features is bad, while acknowledging that too few is just as bad. In this post we will look at what we can do to apply these insights and also change the rules some, making our software more desireable than our competition.
Consulting / Foundation series / Process Improvement / Project Management / Software development
Posted on:
Foundation Series: Basic PERT Estimate Tutorial
PERT is a technique for providing definitive estimates of how long it will take to complete tasks. We often estimate, or scope, the amount of time it will take us to complete a task or tasks. PERT allows us to provide not only an estimate, but a measure of how good the estimate is. Good estimates are a critical element in any software planning strategy. In this post, we will present an introduction to using PERT, explain how it works and how to interpret PERT estimates.