I recently explained to my team the objectives our automated test strategy had to fulfil:
- Provides “living” requirements documentation
- Results in a comprehensive regression test suite
- Ensures high functional coverage
- Runs fast for developers
Tag Archives: quality
Agile Requirements Snail: Feature to User Story to Scenario
The Iterative Incremental approach inherent in Agile applies to delivered functionality but also to the requirements elicitation part of the process.
I like to refine requirements over time. Start high level, just enough to remind us to have a conversation, then fill in the detail just as we need it. What starts as a simple name of an Epic Feature will turn into multiple User Stories each with several Scenarios. But you don’t need all of that at the start.
The iterative nature of requirements definition is suggestive of a spiral process – what my daughter would call a “snail”:
Agile Requirements Snail
Nine Common Strategies for Managing a Growing Defect Backlog
In response to my request for questions along the lines of what do I do when … ? Jo asked:
What do I do when the defect backlog keeps growing with low impact (and low priority) defects and nobody seems to pay attention to them as we have more important features (or medium/high) priority defects to deal with? Should we deal with it or just stop logging low impact defects?
Faults are an inevitable part of software delivery. I only briefing touched on managing lists of faults in Agile Project Execution so it is well worth expanding on.
In fact defects is an area where software delivery, including agile software development, can get messy. Luckily there are ways to manage this mess or to avoid it altogether. Jo’s question hints at potential answers but there are others. In fact I know of at least nine common strategies for managing a growing fault list.
Continue reading
Can Cucumber save Raja?
I’m worried about Raja. Unless I do something drastic he’s going to die. In a rather messy and unpleasant way. Crushed by the weight of a 60 person-year software product.
But I think I’ve got a solution. Cucumber might well save Raja from his gruesome fate.
Continue reading
Simon’s Critical Success Factors for a Software Release
I was on leave for a week and when I got back I found a new flip chart was on the wall.
Critical Success Factors when we release:
- Functionality – Does it do the job?
- Usability – Does it do it well?
- Performance – Does it do it fast?
- Evolution – Does it build smoothly on what is already there?
- Delivery – Is it ready on time?
- Comms / Training – Have we told people about it?
Agile Quality Management
Quality Management, in a project context, is concerned with having the right processes to ensure both quality product and a quality project. This article describes Traditional Quality Management, Agile versus Traditional Quality Management, Agile Product Quality, Agile Project Quality, Agile Product Quality, Agile Quality Assurance and Control, and Agile Quality Improvement.
Continue reading
Agile Project Planning
No battle plan survives contact with the enemy
Plans are nothing, but planning is everything
Field Marshal Helmuth Graf von Moltke
I believe that Agile Project Management provides certainty of delivery. Planning is what lets us answer the question “When will you be finished?”. Planning is, however, just the start of the process. As Moltke pointed out planning is more important that the plan because once you start the project you’ll find the plan is wrong and you have to adapt. All plans need revisiting and you will have to use Agile Project Control, Agile Change Management, and Agile Risk Management to get the promised certainty of delivery.
Continue reading
Agile Risk Management
Risk management is about identifying, addressing, and eliminating sources of risk before they become a threat to the project. This article outlines traditional risk management, how Agile is a risk mitigation strategy, and how to do Agile risk management.
Continue reading
One Page Agile Standard for team of 350
For the last two years I have been rolling out a standard Agile approach to a department of 350. One part of the roll out strategy was to have a published standard. This was to make the goal / end-game obvious even if we didn’t initially mandate everything.
The first version of the standard, published Oct 2006, was a 50 page document. Earlier drafts had been quite short but in reviewing the document people kept asking “What does that mean?” so we’d add another section explaining it. All rather worthy but, aside from the initial reviews before publication, nobody read it. And it diluted the document as a standard, defining what must be done, as opposed to a guideline about how to do it.
We published version 2 today. This version of the standard is one page. I want to give people a simple checklist so they know whether or not they are following the standard.
Continue reading