Kano Model This article will cover you the basic uderstanding about the Kano Model. Kano from the name of Dr. Kano, is a quality mode or estimation model based on the user requirements. Model Kano works suitable with CTQ (Critical to Quality) characteristics. CTQ will remember you what the Agile principles said “YAGNI” – You aren’t gonna need it. YAGNIS is a principle when we want to develop a software feature for the tomorrow requirement without the need from the user. CTQ has three categories Must be / Essentialy Needed / Basic Deliver Performances / Business Value / Performance Delighter / Nice to Have / Excitement Please beware that the priority is different than story points on a user story. it justifies a feature based on priority. Some peoples also use M-L-E-I-R-Q model (please the reference for more information about this). it gives you a wide selection of priority and it will be great if you use questioner for this approach, whereas the three categories above is great when it is implemented for observation or interview. Quick Steps on Agile Estimation Choosing the right model of requirements approaches (interview, observation, or questioner). Choosing the right model for priority model (Kano, MOSCOW, simple numeric, etc) Sort out the story based on its priority Give the story its story points. Measuring the release length and iteration length. Filling the user story into the iteration release. you can put the story based on several technique such as normalism techniques (gaussian), important thing first, or equality technique Example For example, I have questionere the potential users. and use KANO model with M-L-E-I-R-Q. I got 3 story M, L, E 7 story I 3 story R, and Q Let’s make it simple, if M, L, and E category has 20 story points so that I have 60 points (3 x 20), if I story has 10 points therefore I will have 70 points (7 x 10), and if R & Q has 5 points, I will have 15 points (5 x 3). It has 95 points. If my team has velocity of 30 story points, and the contract is based on cost scope on two months. Therefore it will have only 60 story points / realease. It shows that the project doesn’t cover the 35 points (95 – 60 points). It means you should select only 40 points from the I classification feature. In order to select the I features, you should re-priotize or do others requirements process to sort the I features based on the user need. You should remove 30 points and pick only 40 points from release plan References
Sometime a client want you to estimate how much the budget will take and how long the app will be ready. Estimation might not be precise but it will be worth to see the capability of your team to solve the project. According to Boehm (2000) estimate software can be defined as a cone of certainty. you can estimate precisely when you are in the end of the project (and I guess it will become so clear since you already do the project).
As you can see in the first installment of the project your estimation will be 4x wrong or 1/4 better. For example, you estimate that the cost for your development is $1000. If you are in initial concept you might be spend $4000 (4x) or just only $250 (1/4x). The same technique can be applied in time, if you expect you need 40 days you might get 160 days or just 10 days. Interesting huh.
You can use the cone of estimation just like McConnell in his book (please see references). Or you can use Global eXtreme Programming technique to estimate the project. This post will discuss the basic,
The Art of Agile Estimation in GXP
Global eXtreme Programming is a software framework that you can use to adopt eXtreme Programming Agile method in global or distributed environment. If you don’t know about GXP you can download the publication here. The GXP estimation will take five step and I barely sure that you can follow it with an easy.
Step One- Get the user story
If you are using user story in your requirement gathering you are in a right way, but if you are using use case not to worry this method is just same. Writing down any requirements in user story and use case. just browse my post to know about how to create user story or read this book to learn about user story here
Step Two-Estimating The Effort
This is the main effort of the estimation. The estimation somewhat complex but you can do it easily/ I saw several team use COCOMO, FP, or even user story estimation. If you want to read more about the estimation model you can read and buy this book. Trust me is really valuable
Agile Estimating and Planning
Step Three-Having The Priority
You already estimate it now prioritize it.The common priority model is using MOSCOW model or rank model. MOSCOW model is good enough when you have really limited time to tackle many user story in a release.
MOSCOW = MUST , OUGHT , SHOULD, COULD, WON’T
The idea of the MOSCOW approaches are done by mapping the user story with the one of MOSCOW component.
Step Four-Measuring The Team Velocity
This step will measure the velocity. Team velocity can be measured if you have a solid team. It is imposibble to measure the velocity if your team is in dynamic shape (easy come and easy go). The formula to measure the velocity is simple. Just do as follows:
Write down the performance on each project iteration. i.e. 20 stories for 2 weeks in project A.
Find the best of three, the bad of three, and the average. write it down in your log book
Calculating the average. The result should be like this; 20 stoies in the best condition, 15 stories in normal conidition, and 13,5 in bad condition
you can read a good book about the estimation in eXtreme Programming here
medianet_width = "600";
medianet_height = "250";
medianet_crid = "858385152";
medianet_versionId = "3111299";
Step Five-Giving THe Realistic Estimation
Time to polish your estimation. Realistic estimation is done by measuring the good, the bad and normal conidition just like in ste four. It is mean that when you estimate something you should state about the worst case too. For example, when you can achive 2 months project in normal condition. It will be great if you tell the client about the possibility to deliver in a late one. You can estimate the lateness by measuring the teamm when in a bad condition
Having a question, just drop me an email or put your comment below. Thank you.