Agile estimation & planning

You might encounter several weird buzzwords when you're reading about agile estimation methods. This blog tries to give down to earth discussions to help understanding.

Planning Poker
A method to estimate work amounts, which inherits some similarities to the poker game.
The steps:
1. every team member gives an estimation for each user stories (e.g. 8 man-hours for the "customer registration GUI" story), but the number is hidden until all the members have given their estimations. You can use a real set of poker cards to make the process more fun, each team member chooses a card number then puts it upside down to hide the number.
2. when everybody has given his/her estimate, discuss the numbers (e.g. Jip believes that building the GUI will cost 6 points using Struts, Janneke gives 2 points instead using simple PHP, the team will discuss the pros/cons of each method/estimation)
3. repeat the process until the numbers converge (the team members estimates become closer & closer to each other)

Variations:
• online instead of face2face planning meeting, e.g. using http://planningpoker.com/ , but I think face2face will be better & more fun than an online one, but perhaps not always handy for distributed teams.
• publish the user stories and let people outside the team to estimate. e.g. All the developers in the Jip & Janneke team has no experiences with SOA. Annie, a colleague in another team, has extensive experiences with SOA, so Annie can help to estimate the SOA user story. Beware that as the estimation comes from outside the team, it might not reflect the velocity of the team, but at least it can be a starting point for further discussion/estimation.


Tabletop estimation
Another estimation methods by arranging the user stories on a tabletop.
The steps:
1. write all the user stories in small cards
2. compare and arrange the positions of the cards based on their magnitudes (e.g. the story "buying an ice cream " is simpler than "arrange a marriage" so we put "buying ice cream" on the left)
3. Discuss the orders and change if necessary.
4. assign the numbers for each of the stories
5. discuss the numbers.


Simple Release planning
The numbers of iterations = total story points / velocity
The numbers of remaining iterations = remaining story points / velocity
There are many ways to define the velocity, e.g. the average the N last velocity or pessimistic (the average the N worst velocity).

Slacks/buffers
A slack is extra time that you put in your schedule. It might help you to save your deadline when you're overrun with schedule, otherwise you can use the slack time for:
• refactoring / paying technical debt
• learning a new framework / research time
Buffers basically serve the same idea, you can use features buffers and/or schedule buffers.

Fibonacci numbers
When coosing an estimate number, Mike Cohn proposed to use Fibonacci numbers (i.e. each number is the sum of its previous two) e.g. 0,1,2,3,5,8,13, 21,34... instead of just a simpler integers (e.g. ...,4,5,6,7,8,...). The reason is that the bigger the order of magnitude the bigger also the uncertainty (i.e. the gap between the numbers). Personally I prefer to use just simple integers.


Incorporating risks to your planning
The risks will prolong the remaining number of iterations above:
The numbers of remaining iterations = ((remaining story points / velocity)/ risk multiplier)- total risk exposure.

So there are 2 risk factors that will prolong the project: the total risk exposure (due to the project-specific risks e.g.some developers may sick/leave) & the risk multiplier (due to general risks e.g. how stable the development process in this company):

The delay due due to the project-specific risks is quantified by:
The Total risk exposure = sum_i (probability_risk_i * cost_risk_i). For example we have 2 risks: Bumba the GUI engineer who is often sick (probability 0.4 to cost the project 0.5 iterations more), and the Circus server thats need an update this month (probability 0.9, will cost the project 1 iteration more). So the total risk exposure = 0.4*0.5 + 0.9*1 = 1.1 iteration.

The velocity reduction due to general risk is quantified by a risk multiplier table:

As we see in this table the general risk is expressed in probability, thus the resulting remaining iterations estimation is not a (deterministic) point but a (probability) bar. So in a risky process (e.g. the Circus devteam just moved to the SOA environment for the first time), their velocity will be affected by 2x slower in the 0.5 probability case and 4x slower for 0.9 probability case.

---

How's about your experiences with planning/estimation methods? Which works and which doesn't? Why? Please share in the comment.

Source: Steve's blog http://soa-java.blogspot.com

References:
Agile Estimating and Planning


The Art of Agile Development


Agile Software Requirements

Performance testing

Don't guess, test it!

Why performance test:
• to know the performance (e.g. can I handle 100 users, how fast I can refresh the GUI)
• to know how well it scales (e.g. how if I got 10x more customers)
• for tuning the parameters, design / architecture decision, queries

Tips:
• instead of postponing the performance test until the development finish you can do the performance test early in the architecture design phase / spike solutions, to choose which framework to use e.g. JSP or GWT/Ajax, hibernate or ibatis. In the early phase of architecture definition, the cost of a wrong decision can be expensive/irreversible. Consider that if you wait until you finish with the product and then you discover that you have made a wrong choice in the early design then your developer need to spend time again to redo the works (e.g. redo the JSP to GWT/ajax).
• With agile/test driven development spirit, even you may incorporate the performance test to your continuous integration / regression test.
• environment specific: the test result in your development PC will be different with the result in the production server, so use test environment as close as possible mimicking the production
• use different hardware to measure the statistics than the hardware which is being tested
• remove data which damage the quality of statistics (e.g. the initial burn-in period)
• use random think time

Steps:
1. preliminary test: explore (e.g. range #users), set test environtment params (e.g. jvm heapsize)
2. baseline test: typical usage for base comparison
3. stress test to the limit: increase the load until breaking, to know the limit, the bottleneck, the behavior in degradation mode
4. endurance test: load test (high load but not yet overwhelm) for long hours, to detect memory leak, resources/connections which are not properly closed, to know the fail behaviour (e.g. error handling)
5. stress test to fail: deprive the resources (e.g. overwhelm the cpu with other heavy tasks, turn off the networks), to know the fail behaviour (e.g. error handling)
6. vary the parameters (e.g. java heapsize, #clusters) / architecture (e.g. load balancer) / sql query / business logic, then repeat the baseline and stress test to limit fase, compare the results if it improves.

monitoring (to know where's the bottleneck):
• application: eclipse tptp profiler
• jvm: java profiler
• database: oracle trace, query optimizer
• os: top, vmstat, perfmon
• networks: packet sniffers (e.g. tcpdump), netstat, netprotocol analyser (e.g. ethereal)

How
1. define the metrics
2. simulate usage. Run a testrun, which run testscripts (which consist of requests/queries to simulate usage profile)
3. define sampling methods (e.g. fixed #cycles or fixed time window)

Performance metric
• use a clear/specific performance criteria, e.g. not "the web should be as fast as possible" but "the user get a confirmation after click the submit button with max response time 10 sec (given 100 simultaneous users activities)"
• for GUI, the metric can be max response time given #users
• for back-end (e.g. web services or database), the metric can be #transaction per sec (TPS)
• you can define also over limit behaviour e.g. 10% degradation response time with 1000 users.

The statistics:
a. Average response time (ART): aritmetic mean for all user
caveat: if the ART is within limit it doesn't mean that all user instances are within limit.
suggestion: draw the ART vs time (test cycles)
b. Average ART (AART): normalize ART with number of requests, so it will be comparable between different testscripts.
c. define the throughput transaction per sec (TPS): e.g. #(group)queries/sec in database or #messages/sec in JMS
d.Quality: standard deviation / average, prefer bellow 0.25.
e.g. compute standard deviation of ART(as a function of cycles) and divide by ART average over #cycles.


Tools, examples:
test: soapui, httpperf,junitperf,grinder,jmeter


Please write your comments about your experiences with performance testing.

---

Source: Steve's blog http://soa-java.blogspot.com

References:

My blog which mentioned about the use of performance test in the countinous integration test:
http://soa-java.blogspot.com/2011/03/soa-continuous-integration-test.html

J2EE Performance Testing by Zadrozny et.al.


Grig Gheorghiu's blog, a good place for information about testing, python and linux tips.
http://agiletesting.blogspot.com/2005/02/performance-vs-load-vs-stress-testing.html

Performance Engineering
http://performance.punebids.com/

Why planning based on features instead of activities

The conventional way when you make a Gantt charts for planning is by typing the list of activities (which are derived from your statement of work/SOW) in your Work Breakdown Structure (WBS). However, in Scrum/agile, we are recommended to setup our plan based on the software features (e.g. user stories, requirements) instead of a list of task activities.

The reasons, some problems may arise by focusing in the activities instead of features during planning:
So you focus on your development activities (which may have less values to customer) instead of customer values.

Your focus is on finishing activities instead of delivering features which the users need. When the project is behind schedule, people tend to crash by reducing the works to do. If you focus on the activities, you will reduce the activities which are prioritized for the convenience of the development team. In this process you may dropping features and some of the dropped may have greater values than those are delivered.

When you check the completeness of the works, you will check the completeness of the activities instead of the requirements of the product (which are more relevant to the users.)

What are you experiences with this issue? Please write your comments.

---

Source: Steve's blog http://soa-java.blogspot.com

References:
Agile Estimating and Planning

Choosing open source / free Scrum tools

I would like to have a free Scrum tool which have these features for planning & progress reporting:
• virtual task board (to show which user stories in the current sprint / sprint plan, release plan)
• burndown chart
• backlog (prioritized list of user stories)
• velocity chart
• Gantt chart / iteration timeline

I found at least 2 tools that fulfill those criteria:
• Icescrum http://www.icescrum.org/
• Agilo http://www.agile42.com/cms/pages/agilo/
Agilo has a better documentation than Icescrum and also offers integration with trac & svn, but you need to pay for Pro license for using the virtual board (& many other handy functions), about 800 euros for 10 users/year. So finally I decide to use the Icescrum instead. Icescrum is just a web application (a war file) that you can install for example in Tomcat. You can testdrive the icescrum here: http://www.icescrum.org/demo/

Some screenshots from http://www.icescrum.org/:

Burndown chart & activities


Virtual task board: release plan /sprint plan


Which agile/scrum tools/project management tools do you use? What are the advantages/disadvantages of those tools? Please write your comments.

---

Source: Steve's blog http://soa-java.blogspot.com

References:

Comparing Open Source Agile Project Management Tools by Brad Swanson
http://olex.openlogic.com/wazi/2009/comparing-open-source-agile-project-management-tools/

Scrum and XP from the Trenches by Henrik Kniberg
www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.pdf

Agile Estimating and Planning

Design document: to write or not to write

One of the tenets from agile manifesto says "Working software over comprehensive documentation". Unfortunately many lazy (agile) developers use this manifesto to excuse that "we don't have to write documentations at all". Some developers claim that they are agile when they follow the no-documentation principle without practicing other agile principles (such as early & frequently deliveries.)

I believe that writing simple documents (such as use-case, requirements list and architecture design) is still beneficial yet in the agile context.

There are several benefits of a written design document (whether as up-front design or during the iterations):
• you can distribute it to many people (also across the continent) to get feedbacks, so you don't have to explain again & again orally.
• To get feedbacks in the early phase while you defining architecture is important. Despite using agile process, you can't denied that the cost of changing your initial architecture decisions will get more and more expensive as you proceed in the development phase. The cost of repairing a wrong decision in the early phase (architecture) is expensive. You can get better feedback by writing the requirements & the architecture clearly in documents.
• if you don't write you can easily overlook/forgetting important details (beware: the devil is in the details), other people can review the list in your documents and add/comment.
• You can postpone some risky decisions and delay the design which most likely to change, but at least you need to mention the indecisive issues, the risks and the assumptions in your design documents, it will serve like a checklist that you/others can refer later to discuss.
• If you leave the company/project or if you delegate the project to others, the next person doesn't have to start from scratch. It will be easier also for the next people who have to extend the finished product, so they understand the reasons behind you decisions.

Please read my blog about "Software architecture design document"
http://soa-java.blogspot.com/2011/06/software-architecture-design-document.html

How about your experiences with trade-off between the rigorous (RUP) documentations & agile simplicity in your organization? Please write your comments.

---

Source: Steve's blog http://soa-java.blogspot.com

Reference:
Agile Manifesto

How to define your team: fixed teams or project based?

We consider 2 ways to form developer/tester teams:
1. Use a fixed team that move together from one project to the next.
2. Form a new team from a developer pool each time a new project come.

In my opinion using the first approach (a fixed team) is preferable than the second (project based team).

A fixed team will be more productive since its members have learned to trust & anticipate each other (regarding competences, work styles, personalities). Besides, it's easier to measure the velocity (thus improving your estimation & planning) with a fixed team. On the other hand, you need to give time for the team to "gel", once the team spirit is formed the productivity will increase.

A scrum team facilitates itself for this fixed-team approach. The daily scrum meetings facilitate the face2face communications between team members thus strengthen the "glue" inside the team, good for bashful geeks who otherwise will hide the whole day behind his PC.

Strangely enough, my observation of the drawback of a project-based team came from outside the professional works. I can share an experience in our church music team. As one of the biggest church in the Netherland, we have lots of talented musicians in the pool. Every week we will draw a set of band members from the pool. We spend the first hours of weekly exercise struggle to blend as a new team, so less time left to build the musical quality nor to worship as a team.

As conclusion, teams are harder to build than projects so it's better to form a persistent team that move together from one project to the next.

How's about your experience in your organization (work, church/community project etc)? Please share your comments.

---

Source: Steve's blog http://soa-java.blogspot.com

Reference:
The Clean Coder by Robert Martin



Disclamer: the 'bash-ful' term in this article has nothing to do with the bash shell in Linux.

Using openSSH

Ssh/scp is more secure than telnet/rsh/rcp due to encryption and server verification through certificates. In this blog we will discuss 3 issues: how to verify that you connect to the genuine server, how to create new keys in case that your keys have been compromised and a handy method to do ssh/scp without password.

1. How to verify a server connection
The first time you tried to connect to a server using ssh, you will be asked to verify the public key of the server:
> ssh auser@aserver
The authenticity of host 'auser(ip address)' can't be established.
RSA key fingerprint is bla:16:ee:ec:0b:19:5e:0b:33:c7:9f:ef:bla:bla:bla
Are you sure you want to continue connecting (yes/no)?

Once you say yes, the public key will be saved in your ~/.ssh/known_hosts file. Bear in mind of the man in the middle attack, how can you be sure that you communicate with the genuine server? A way to check by comparing the fingerprint of the server's public key with the fingerprint stated above. The server public key is located in the /etc/ssh/ssh_host_algorithm_pub.key file. Having this file (perhaps mailed by the admin of the server) you can generate the fingerprint using 'ssh-keygen -l -f public_key_file' and compare the values with the fingerprint above.

2. How to create new keys
If you're in a situation where your server keys have been compromised, you can generate a new pair of ssh public & private keys in the server, using ssh-keygen or open-ssl for example: 'ssh-keygen -t algorithmname', substitute the algorithmname with RSA or DSA. Use ' Hostkey keyfilename' to assign this key as the new ssh key. It's a good habit to regularly renew your keys just in case that the current key has been compromised.

3. Ssh/scp without password (authentication via PKI / X.509 certificate)
It will be handy to avoid being asked to type password everytime you use scp/ssh. Here are the steps to accomplish this: generate client keys using ' ssh-keygen -t algorithmname' in ~/.ssh directory. Substitute the algorithmname with RSA or DSA. Then copy the public key to ~/.ssh/authorized_keys in the server.

---

Source: Steve's blog http://soa-java.blogspot.com

References:
Foundations of CentOS Linux by Chivas Sicam and Ryan Baclit


Man in the middle attack http://en.wikipedia.org/wiki/Man-in-the-middle_attack
Convert keys between OpenSsh and OpenSSL http://www.sysmic.org/dotclear/index.php?post/2010/03/24/Convert-keys-betweens-GnuPG%2C-OpenSsh-and-OpenSSL