Agile Estimation - The East Agile Way
Agile Estimation Of Iterations
If you haven’t done so already, take a moment to read the blog on Reliable Estimates Using Agile.
Agile EstimationBefore You Start Once again, lets make sure that you have everything you need to start estimation. So:
If any of this is missing, then you probably aren’t following the agile rules and need to take a step back before estimation. IterationAn iteration is a period of time that work is done. Typical durations range from 1 week to 1 month. At East Agile, our iterations are short: 1 week. So, in the iteration planning meeting, we are estimating what User Stories we will complete in 1 week. Commitment Keep in mind what was covered about Agile Estimation and Reliability. You, as a team, are committing to the User Stories you say you will complete in the iteration. The User Stories you commit to end up on the Current Log (see Pivotal Tracker for more information on current logs). Iteration Planning - Where You Estimate Estimation and commitment is done in the iteration planning meeting (in Scrum, called the Sprint Planning Meeting. As I noted before, we did not create this great agile process. We just use it without the branding). Iteration Planning CallA time boxed call (2 hours (5% * 40 hours) involving product owner, team and stake holders (optional but can’t talk) and domain experts (optional: Available to answer questions). The purpose is to estimate out and commit to the next iteration of work by clarifying the user stories with the product owner and estimating them while the product owner listens in. Sometime Before the Call
During the callFirst half (Time-boxed 1 hour) In the first half of the call:
Second half (Time-boxed 1 hour)In the second half of the call:
Highly Recommended Rules and Notes:
Iteration Planning Call Partially-Explained Just listing our rules isn’t going to help you understand why we follow these rules. The rules themselves are based on best known agile practices. ConclusionAt East Agile, we use Agile Estimation processes in conjunction with Pivotal Tracker (www.pivotaltracker.com) to assure reliable and useful estimates. Useful estimates are provided in a fully transparent manner allowing the Product Owner to make educated guesses on the ROI East Agile is providing in the current iteration.
It is through these proven Agile processes that we are able to commit to and deliver products on time through weekly iterations.
Screen Shot: Pivotal Tracker
|
Reliable Estimates Using Agile
Reliable Estimates Using Agile Estimation is actually quite easy as long as you keep your expectations under control and follow the rules. Reliability and AccuracyReliable Estimates that are Useful and BelievableEveryone wants reliable estimates that are useful and believable. An estimate is reliable when the team can assure they can deliver the User Story on time (“Acts of god” don’t count). Always delivering on time builds trust and reduces risk for the customer. Accurate EstimatesAn accurate estimate is an estimate that falls close to the actual time it took to get the User Story approved by the Product Owner. It is hard to be accurate in estimation and very hard to be accurate and reliable. There are a lot of factors involved in making an accurate estimate (see Adjusting For Risk Below). Agile Doesn’t Require Accurate EstimationWhat makes agile estimation so powerful is that you don’t need to be accurate. You just need to be reliable. Estimation is done with story points, and in every iteration everyone can see how many story points are completed. After 3 or 4 iterations, a pattern emerges called velocity. Velocity is the natural accuracy of a team.A team that is able to complete 10 story points in 5 days has a velocity of 2 stories points per day (Velocity is usually per iteration). A team could try for 10 story points a week and that should be accurate. To be reliable, a team could try for 8 - 12 story points keeping the product owner aware that 8 is the absolute minimum that will be delivered: a very reliable estimate. Of course, if velocity is all over the place then it means the team is having trouble estimating. There are ways to mitigate this as I will discuss in the blog on Agile Estimation. The Dangers of Estimating for AccuracyAn accurate estimate improves your chances on getting a new customer. However, it also increases the chance of losing an existing customer. After all, the Product Owner wants a reliable team with useful and believable estimates. A team always missing their deadlines simply because they are trying to be accurate will cause the Product Owner to loose faith in the team and eventually the company the team works for.Preparation Before EstimationBefore estimation you need:
Estimating a User StoryRight, so you are on a team (. You know your availability and all your team members availability. You’ve studied and actively applied the definition of done for the project. You have user stories clearly defined by the Product Owner. Let’s being.Writing User Stories that can be EstimatedIt is very important that a story can be estimated. What makes a good story which can be estimated?
The Agile Estimation ProcessFinally, the agile estimation process is applied to actually estimate the stories. Instead of writing about this process in this blog, I will provide another blog that focuses on just the agile estimation process.Choosing the Hard Stuff FirstThis does not have an effect on individual stories but does have an effect on the success of the project as a whole. It is of utmost importance that the riskiest stories are completed first. If a specific unknown technology actually doesn’t work, it might mean the entire project is not possible. It is better to find that out before all the money is spent.Adjusting For RiskThis is an incomplete list of things you can do to improve on your estimates.
ConclusionEstimation is not only possible but it can actually be easy. You simply have to follow the agile estimation process and keep in mind the key points brought up in this blog. Remember, you are trying for reliability that is useful and believable. You don’t need accuracy as that emerges naturally from the agile process itself.Next week I will blog about the agile estimation process.
|
"Managing" a Project to Success Using Agile
|
Agile tools shine at managing projects and providing quality. But what is required to “manage” a project to success? What is the purpose of a project? The purpose of a project is to provide a deliverable: a product or service. A deliverable is defined using specified requirements. Quality is meeting the specified requirements using measurements based on quantitative objective evidence. To provide a deliverable, the following are required:
When an organization comes up short on any of these key attributes those involved will try to fill in the gaps:
Those involved then meet their own expectations, as opposed to the key stake holders expectations, and claim success against “overwhelming odds”! This means there is a gap between what is delivered and what was promised to be delivered: the specifications. What you have then is project failure. How Does Agile Assure Success?
The following are just a few examples of how agile assures that a project is successful:
The key thing to note from these examples is that everyone has responsibility clearly defined by the agile rules and the authority to execute that responsibility. When software is the deliverable, agile defines in great detail the tools required (such as test driven development, regression testing, pair programming, agile estimation, iteration planning meetings, etc.). What I’ve written above is based on the Kaizen (http://en.wikipedia.org/wiki/Kaizen) philosophy of continuous improvement. One of the reasons why agile works so well, and specifically agile management concepts, is that it is also based on the Kaizen philosophy. From here on out, I will focus on key aspects of agile and how they fit in with assuring a successful project: providing a quality product. [ED: you may notice a lot of similarity between the East Agile Master and a SCRUM Master] |
Website History
|
Some things on the Internet can disappear in a flash, leaving no trace of their ever having existed. But a lot of the web remains permanently archived. For better or worse, this can remain a part of history. In 1996, Brewster Kahle created an archive of the web with part of the fortune he made from Alexa. See Archive.org. He had retired into the modest life of a "librarian" as he described himself then. Today, because of his work, and that of others, and similar projects, we can see what the web was like in the past. As an example, you can see what our website (under our original Stanyan Group brand) looked like back in time. 2002
2001
1999
(N.B. The Stanyan Group was incorporated in California in July 1997).
|
East Agile and Agile Tools
|
One of the great aspects of Agile is that it can be continually reviewed and improved through retrospection. At East Agile, we apply Scrum, an Agile management process, but with a few changes. Agile itself is a collection of tools that are available to Agile users (Pair Programming, Standup meetings, Retrospective Meetings, Test Driven Development, etc.). XP (http://www.agilealliance.org/), Scrum (http://www.scrumalliance.org/ ) and Crystal (http://alistair.cockburn.us/Crystal+methodologies ) are examples of branded systems that draw from the set of Agile tools available. As such, there is nothing wrong, and it is quite Agile, to draw the best from these branded Agile systems (just as the founders of Agile did when they choose which tools were most Agile when engineering). Scrum, as it stands, expects easy access to the Product Owner, all Stake Holders, the Scrum Master and the Team. Scrum also suggests that a minimum iteration should be around 2 weeks. Extreme programming feels iterations can be quicker. I’m not saying there is anything wrong with Scrum as it stands. We greatly appreciate the transparency and consistency that Scrum brings to the table. But our Product Owners are often thousands of miles away. I am going to blog about agile tools used by Scrum and how we implement those same tools within East Agile. Basically, we have been able to make Scrum work when the Product Owner is thousands of miles away: without losing transparency. We are also able to use Scrum and still deliver on a daily basis. I am sure we aren’t the first to do this but this is our story. I think it is important to remember the Agile Manifesto (http://agilemanifesto.org/) which says:
At East Agile, every decision we’ve made in implementing Agile has kept this manifesto in mind. I think it is also important to give special mention to Ken Schwaber(http://www.controlchaos.com/) and Jeff Sutherland(http://scrum.jeffsutherland.com/) for bringing us Scrum. [ED: See Kent Beck's seminal 1999 book: Extreme Programming Explained: Embrace Change. Addison-Wesley. It coins eXtreme Programming (XP). Follow @KentBeck on Twitter] |
Why Paired Programming?
|
It is very important for us to not compromise on paired programming.
If developers work independently on separate parts of an application on a continuous basis, even if they happen to be sitting at the same desk when they do that, then very important problems from solo-programming start to emerge. (1) To the degree that each thread of work is separate, it happens without continuous code review. (2) The same is true about collaboration. Even occasional collaboration on these matters becomes less effective and less insightful because the other person has not built up the mental map of the code base that comes from being involved in the full development process.
Everyone Pair Programs at East Agile, as shown in the photograph above. |
What Facebook applications have you created?
myBrainhttp://apps.facebook.com/
|
Eric Hosick Publishes OO Book
|
|
Banking Vietnam: Hanoi
|
We are attending the Banking Vietnam conference in Hanoi. One key lesson from this is that business analytics and profitability reporting are important missing parts of Vietnamese banking infrastructure. There is also a strong interest in risk management issues and helping Vietnam move from a cash economy to one based on electronic and formal payment mechanisms. |
Is Online Data Private?
|
I was rather surprised today to read that data stored on "cloud" services might not have the same legal privacy protections in the US that data has when stored inside your home (or business). This came to my attention after a Wired Magazine article (April 20, 2010) about Google's recent openness about government worldwide requests for information.
The principle is that user data left online more than six months can be considered "abandoned" and so open to less restrictive government scrutiny. The primary, or at least initial, target seems to have been email. But the law could apply to phographs, usage and other behavioral data, friends, and status messages. As far as I can tell, this applies to just about any personal data stored online. What to do about it? One way to resolve this issue would be to insist on storing data online only in encrypted form, with all decryption done on the client side. Currently, to ensure security, network connections between client and server are encrypted. But the data is then stored in clear, unencrypted form, exposing it to employees, theft, and government access at the host company premises. This could help with some data, intended for the owners eyes only, such as email and personal documents. But this would not work easily for data that is intended to be shared with a limited audience. And this would not protect behavioral data, such as login times and places, and purchases. As a stop gap measure, individuals and companies should consider deleting all data, including behavioral data as it grows older than 6 months. One could also lobby to get the laws changed. But there are a lot of competing interests, and success is not inevitable, or likely to be rapid. However, an important solution should be legal, and some action in that direction is starting to take shape.
|

In this blog, I will talk about the actual process of estimating an iteration and specifically how we do it at East Agile. I had the chance to take 











Eric Hosick's first book should appear on Amazon in a few days. It is a careful distillation of the core object oriented programming concepts every programmer should know. Eric recently joined the East Agile development team, and I congratulate him on his contribution to the larger developer community.