AGILE ESTIMATION An Introduction Nischal S AGILE ESTIMATIONS

AGILE ESTIMATION An Introduction Nischal S

AGILE ESTIMATIONS T-Shirt sizing Planning Poker Relative Mass Valuation

T-SHIRT SIZING Putting a number to effort is difficult. Arriving at a accurate number is difficult. The story points does not accurately map to number of hours. So guess estimation through non-numerical values. T-Shirt sizing provides for relative estimations. Generally approach is used for starting of agile in team. Common values (XS, S, M, L, XL, …)

T-SHIRT SIZING EXAMPLE Estimate the below application using T-Shirt sizing: A client/ Server chat application – which accepts a user name and retrieves from server all Online/Away chat clients and allows them to chat with each other. There is no conference or group chat but one user to another. User has option on status – Online and away. Clicking on a user in list box, will load the chat data for that user. When application closes, it does not archive any chats. The application should support minimum of 10, 000 active users at a time and maximum of 30, 000. The development to be done using TDD.

T-SHIRT SIZING EXAMPLE Estimate using T-Shirt sizing- some considerations: Design / analysis of the application. Write all unit tests – Server, client. Develop Server application- WCF/ html rendering in windows/session handling/temp data store for active clients? Stress test Server for min and max users – refactor/load balance/threading/session handling? Develop client and establish connections to server – port settings/ firewall / controls binding? Estimation ≈ L(more than a week)

T-SHIRT SIZING Disadvantages: For multiple stories in sprint these does not provide for summation. (Eg. 3 M , 2 L and 1 XL) Individual perspective of sizing is different. (XL can be viewed by person A different from person B). There is no way of measuring the progress? (burn down chart) Also there is non-uniform gap between the sizing. (XL is 33% bigger than L, but not the same between L and M). But provides for a platform to start with Agile and then minimally put some underlining numbers to sizing (S=5 h, M=14 h, . . ) and gradually shift to numeric estimations.

PLANNING POKER Everybody in team counts. Individual opinion is considered. Enables team understanding of tasks due to discussion. Story points: arbitrary measure on effort required on tasks. Fibonacci series (0, 1, 2, 3, 5, 8, 13, 21. . ). This does not relat to hours! This is a game which team members can play! Each team member is given a Fibonacci poker card set(0… 21). Story detailing is done to team. A timer is set for team members to present their estimation relative to card numbers. The team members with highest and lowest estimations are to explain rational behind their numbers, if there is greater parity. PO/SMEs / Architects can contribute to these thoughts on complexities involved. Either re-vote or reach consensus on estimation. Even after 3 iterations if the story points does not converge then use average and converge to nearest Fibonacci number. Mike Cohn (November 2005). "Agile Estimating and Planning".

PLANNING POKER Why Fibonacci series? Mike Cohen suggests this because stories does not provide mathematical accuracies. The series takes a steep climb instead of a gradual climb, there by helping in classification of story it terms of complexity. Story points are not hours, but how to arrive at a number? How to estimate a story as story point 3? Team will find a baseline story and benchmark their story point. This necessarily need not be 1 point. Then compare each story with this baseline story. Note : For two teams story points are different as their baseline is different and hence the velocity is different! Mike Cohn (November 2005). "Agile Estimating and Planning".

PLANNING POKER EXAMPLE Baseline story: Display a button on a main form and on click show a main form label with “Hello World!” on windows form story Points: ? Estimate the below application using Planning poker: A client/ Server chat application – which accepts a user name and retrieves from server all Online/Away chat clients and allows them to chat with each other. There is no conference or group chat but one user to another. User has option on status – Online and away. Clicking on a user in list box, will load the chat data for that user. When application closes, it does not archive any chats. The application should support minimum of 10, 000 active users at a time and maximum of 30, 000. The development to be done using TDD. Timer: 1 min(Select a number) Reach consensus Story Points : ? Mike Cohn (November 2005). "Agile Estimating and Planning".

PLANNING POKER EXAMPLE Advantages: Accuracy is goal ! If estimation is lower for a story – team will work unsustainable hours leading to burn out. If greater , then developer bandwidth is high. So with each poker estimation team matures to better estimations. Determines the team velocity based on past sprints. Disadvantage: Time consuming than traditional methods. Distributed / different time zones teams estimation is challenging. Online tool ! - http: //planningpoker. com/. Or http: //www. planitpoker. com

RELATIVE MASS VALUATION Large backlog of stories? Do you estimate all of them to commit on achievable tasks on a given time frame? Have stories written on story cards( JIRA ID + Summary). Set up a large table with smaller and larger card on far ends. Pick one story at a time and evaluate if this smaller, bigger and giant item based on complexity. (spectrum of complications from simpler to complex). Size each story card relative to other story cards considering efforts involved. PO/SMEs/Architects can help by providing clarity to story but should not involve in valuation. Once all cards are arranged, then start assigning a story points to each verticals starting from smaller end with 1 and moving to other end assigning high numbers as 2, 3, 5, 8, 13, 21. . This is rough point estimate.

RELATIVE MASS VALUATION Advantges: This could be facilitated for team size from 5 to 45. Backlog containing about 100 stories can be sized in lesser time than conventional estimations(approx. less than hour) Disadvantages: Some stories are new to team and could be over or under estimated. PO might challenge(not disrespect the team members estimates). Those story cards could be marked for discussion to reach a common consensus. Transferring them from table board to a tool!

REFERENCE Software Project Effort Estimation – Adam Trendowicz, Springer, 01 -Jan-2014 Essential Scrum: A Practical Guide to the Most Popular Agile Process. Kenneth S. Rubin, Addison-Wesley, 20 -Jul-2012 Introduction to Agile Methods, Sondra Ashmore. , Kristin Runyan, Addison. Wesley Professional, 23 -Jun-2014