Thursday, 20 March 2014
Just a short note on regression testing – I came across this picture in FunnyJunk.com:
And it reminded me of this excellent guide to regressionstest i have in my link collection:
Have a nice day & Happy regression testing!
Tuesday, 18 March 2014
Problem: Business reviews related to sprint demos needs planning and preparation.
A sprint demo is a formal activity where the customer evaluates the delivery. It is not uncommon that the demo is done for an unprepared audience. The reviewers must be prepared in order to avoid waste of effort and risking ending the demo with a non-decision, or just saying yes to the delivery.
Solution: Prepare your review questions BEFORE the sprint.
It is the product owner and friends who needs to make the decision about accepting or rejecting the delivery. This means that they need to gather as much information as possible to ensure that the decision is done on the right foundation – This calls for preparation, before and after the delivery.
This is what I usually recommend as preparations for a demo:
- Read the back lock items in the release note carefully. Review acceptance criterias and think of positive and negative scenarios, these will serve as a checklist for things that you would like to see in the demo.
- Prepare scenarios for high risk acceptance criterias. Look at daily work and bring some of the cases to the demo, ask for these cases to be used/demonstrated in the demo.
- Review the delivery vs. business process, look for areas where business processes could be obstructed. Ask a lot of questions at the demo, ask for demonstration of these scenarios.
- Put new functionality into context by thinking end to end. Will this have a negative impact on running flows and activities in the system / business?
Remember that the demo is a business review, not a technical review and that is has limitations.
Demo allows a review from the business users checkpoint, it tests the business operability.
Planning and prioritisation is required, not everything can be checked at the demo.
Please remember that the sprint demo is not to substitute more rigorous user acceptance testing. Especially high risk/complexity areas needs much more attention that it could ever get in a sprint demo.
Friday, 7 March 2014
Problem: There is a huge difference between a guesstimate and an estimate.
Since both methods are measured in same variable they can look very similar. They both give some quantitative measures assigned to time or cost, but they differ greatly in in uncertainty.
Solution: Make sure that you ask the right question when requesting an estimate.
Wikipedia says it all about guesstimates: ”It is defined as an estimate made without using adequate or complete information, or, more strongly, as an estimate arrived at by guesswork or conjecture.”
It seems however that some people forgets that estimates are not certain, but over and over again both guesstimates and estimates ends up being the foundation of planning.
From a planning perspective estimates are necessary in order to make the plan, but it does not mean that the estimate cannot be checked. Even estimates from subject matter experts can be challenged by asking the right questions.
I ask these questions when a critical estimate is presented:
- What is the data and conditions used for the estimate?
- What does the estimate cover and what is the scope?
- What estimation methodology was applied?
- Are there any obvious uncertainties?
Data and conditions are important as understanding the estimate parameters and requirements is needed in order to check an estimate. These conditions provide the framework for the estimate and are what the estimate is compared against.
Coverage and scope indicates all the activities that are included, and maybe more important those that are not included in the estimate. The discussion on what is out of scope is healthy in the way that it aligns expectations and understanding of the tasks related to the estimate.
Estimation methodology says a lot about the certainty in the estimate. Applying FIA (finger in air) is often less accurate than planning poker in the development team. Check Wikipedia or other source for more info on the methodologies.
Uncertainties often comes from assumptions or dependencies – Look for those in the discussion and you are likely to uncover the uncertainties while doing so.
Note: this is not an invitation to question every estimate you come across, but a suggestion on how to increase accuracy of those estimates that are on your project’s critical path. Many an estimate you come across is in fact a guesstimates, challenging it might make it an estimate, reducing risk and improving accuracy of the planning in your project.
Happy estimating & have a nice weekend!