Great article by Mike Griffiths: http://leadinganswers.typepad.com/leading_answers/2015/10/agile-talent-management.html
Many people have used a variation of Planning Poker to do Agile estimation. Here is a reference of 9 different Agile estimation techniques for different circumstances. I have seen all of these techniques work in practice, except one. Try a new one each Sprint!
Planning Poker
Participants use specially-numbered playing cards to vote for an estimate of an item. Voting repeats with discussion until all votes are unanimous. There are lots of minor variations on Planning Poker. Good technique to estimate a very small number of items (2 to 10).
The Bucket System
Using the same sequence as Planning Poker, a group or a team estimate items by placing them in “buckets”. The Bucket System is a much faster Agile estimation technique than Planning Poker because there is a “divide-and-conquer” phase. The Bucket System can also be used with larger groups than Planning Poker and with very large numbers of items to be estimated (50 to 500).
Big/Uncertain/Small
For super-fast Agile estimation, the items to be estimated are simply placed by the group in one of three categories: big, uncertain and small. The group starts by discussing a few together, and then, like the Bucket System, uses divide-and-conquer to go through the rest of the items.
TFB / NFC / 1 (Sprint)
This Agile estimation technique is similar to Big/Uncertain/Small but puts a specific “size” into the mix, namely 1 Sprint. The categories are “Too F-ing Big”, “No F-ing Clue” and “1” Sprint (or less). I learned this one recently from someone in one of my CSPO classes.
Dot Voting
Dot voting is usually considered a decision-making tool, not an Agile estimation technique. However, for estimating small numbers of items, dot voting can be a super-simple and effective technique. Each person gets a small number of “dots” and uses them as votes to indicate the size of an item; more dots means bigger.
T-Shirt Sizes
Items are categorized into t-shirt sizes: XS, S, M, L, XL. The sizes can, if needed, be given numerical values after the estimation is done. This is a very informal technique, and can be used quickly with a large number of items. Usually, the decisions about the size are based on open, collaborative discussion, possibly with the occasional vote to break a stalemate. There is a brief description of T-Shirt Sizes here.
Affinity Mapping
Items are grouped by similarity – where similarity is some dimension that needs to be estimated. This is usually a very physical activity and requires a relatively small number of items (20 to 50 is a pretty good range). The groupings are then associated with numerical estimates if desired.
Ordering Protocol
Items are placed in a random order on a scale labeled simply “low” to “high”. Each person participating takes turns making a “move”. A move involves one of the following actions: change the position of an item by one spot lower or one spot higher, talking about an item, or passing. If everyone passes, the ordering is done. The Challenge, Estimate, Override and the Relative Mass Valuation methods are variations on the ordering protocol.
Divide until Maximum Size or Less
The group decides on a maximum size for items (e.g. 1 person-day of effort). Each item is discussed to determine if it is already that size or less. If the item is larger than the maximum size, then the group breaks the item into sub-items and repeats the process with the sub-items. This continues until all items are in the allowed size range.
Agile estimation techniques are collaborative. All appropriate people are included in the process. For example the whole Scrum team participates in estimating effort of Product Backlog Items. Collaborative techniques are also designed so that it is impossible to blame someone for an incorrect estimate: there is no way to trace who estimated what.
Agile estimation techniques are designed to be fast (-er than traditional techniques) and deliberately trade off accuracy. We are not trying to learn to predict the future… or get better at estimation. Instead, we recognize that estimation is a non-value added activity and minimize it as much as possible.
Most Agile estimation techniques use relative units. This means that we don’t try to estimate dollars or days directly. Instead, we use “points” or even qualitative labels and simply compare the items we are estimating to each other. This takes advantage of the human capacity to compare things to each other and avoids our difficulty in comparing something to an abstract concept (such as dollars or days).
Check out my recent “Agile Planning in a Nutshell” article.
What Other Agile Estimation Methods Are There? Please let me know in the comments and feel free to include a link!
Whenever I run a Certified Scrum Product Owner training session, one concept stands out as critical for participants: the relationship of the Product Owner to the technical demands of the work being done by the Scrum team.
The Product Owner is responsible for prioritizing the Product Backlog. This responsibility is, of course, also matched by their authority to do so. When the Product Owner collaborates with the team in the process of prioritization, there may be ways which the team “pushes back”. There are two possible reasons for push-back. One is good, one is bad.
Bad Technical Push-Back
The team may look at a product backlog item or a user story and say “O gosh! There’s a lot there to think about! We have to build this fully-architected infrastructure before we can implement that story.” This is old waterfall thinking. It is bad. The team should always be thinking (and doing) YAGNI and KISS. Technical challenges should be solved in the simplest responsible way. Features should be implemented with the simplest technical solution that actually works.
As a Product Owner, one technique that you can use to help teams with this is that when the team asks questions, that you aggressively keep the user story as simple as possible. The questions that are asked may lead to the creation of new stories, or splitting the existing story. Here is an example…
Suppose the story is “As a job seeker I can post my resume to the web site…” If the technical team makes certain assumptions, they may create a complex system that allows resumes to be uploaded in multiple formats with automatic keyword extraction, and even beyond that, they may anticipate that the code needs to be ready for edge cases like WordPerfect format. The technical team might also assume that the system needs a database schema that includes users, login credentials, one-to-many relationships with resumes, detailed structures about jobs, organizations, positions, dates, educational institutions, etc. The team might insist that creating a login screen in the UI is an essential prerequisite to allowing a user to upload their resume. And as for business logic, they might decide that in order to implement all this, they need some sort of standard intermediate XML format that all resumes will be translated into so that searching features are easier to implement in the future.
It’s all CRAP, bloat and gold-plating.
Because that’s not what the Product Owner asked for. The thing that’s really difficult for a team of techies to get with Scrum is that software is to be built incrementally. The very first feature built is built in the simplest responsible way without assuming anything about future features. In other words, build it like it is the last feature you will build, not the first. In the Agile Manifesto this is described as:
Simplicity, the art of maximizing the amount of work not done, is essential.
The second feature the team builds should only add exactly what the Product Owner asks for. Again, as if it was going to be the last feature built. Every single feature (User Story / Product Backlog Item) is treated the same way. Whenever the team starts to anticipate the business in any of these three ways, the team is wrong:
Okay, but what about architecture? Fire your architects. No kidding.¹
Good Technical Push-Back
Sometimes stuff gets non-simple: complicated, messy, hard to understand, hard to change. This happens despite us techies all being super-smart. Sometimes, in order to implement a new feature, we have to clean up what is already there. The Product Owner might ask the Scrum Team to build this Product Backlog Item next and the team says something like: “yes, but it will take twice as long as we initially estimated, because we have to clean things up.” This can be greatly disappointing for the Product Owner. But, this is actually the kind of push-back a Product Owner wants. Why? In order to avoid destroying your business! (Yup, that serious.)
This is called “Refactoring” and it is one of the critical Agile Engineering practices. Martin Fowler wrote a great book about this about 15 years ago. Refactoring is, simply, improving the design of your system without changing it’s business behaviour. A simple example is changing a set of 3 radio buttons in the UI to a drop-down box with 3 options… so that later, the Product Owner can add 27 more options. Refactoring at the level of code is often described as removing duplication. But some types of refactoring are large: replacing a relational database with a NoSQL database, moving from Java to Python for a significant component of your system, doing a full UX re-design on your web application. All of these are changes to the technical attributes of your system that are driven by an immediate need to add a new feature (or feature set) that is not supported by the current technology.
The Product Owner has asked for a new feature, now, and the team has decided that in order to build it, the existing system needs refactoring. To be clear: the team is not anticipating that the Product Owner wants some feature in the future; it’s the very next feature that the team needs to build.
This all relates to another two principles from the Agile Manifesto:
Continuous attention to technical excellence and good design enhances agility.
and
The best architectures, requirements, and designs emerge from self-organizing teams.
In this case, the responsibilities of the team for technical excellence and creating the best system possible override the short-term (and short-sighted) desire of the business to trade off quality in order to get speed. That trade-off always bites you in the end! Why? Because of the cost of fixing quality problems increases exponentially as time passes from when they were introduced.
Refactoring is not a bad word.
Keep your code clean.
Let your team keep its code clean.
Oh. And fire your architects.
Update Sep. 8, 2015: Check out this YouTube video on the closely related topic of who has authority over the Product Backlog and why developers should not set the order of PBIs:
¹ I used to be a senior architect reporting directly to the CTO of Charles Schwab. Effectively, I fired myself and launched an incredibly successful enterprise architecture re-write project… with no up-front architecture plan. Really… fire your architects. Everything they do is pure waste and overhead. Someday I’ll write that article 🙂
The Product Owner is responsible for the Return on Investment (ROI) of the Product. In order to manage that responsibility, the Product Owner needs to estimate how much financial benefit the Product Backlog Items for a specific Sprint will generate, and compare that to the effort of one Sprint’s worth of the Scrum Team’s labor. This calculation then allows the Product Owner to decide if a given Sprint is worth doing or if the Scrum Team should turn its attention to other work… possibly even a different product. If the Product Owner has these estimates, then it is possible for the Product Owner to maximize the ROI of the Scrum Team. When these estimates are missing, it is difficult to ensure that the Scrum Team is working on the best possible PBIs. In the worst case, the Product Owner will spend the Team’s time working on very low ROI items and cause substantial problems for the business.
To learn more about Product Owners, visit the Scrum Team Assessment.
