Posts tagged "Agile"

Value Team Heuristics and use of Story Points when forecasting

When it comes to estimation in Software development, the difficult question to answer is when can we go to market? and when can we release the product or service? These are difficult questions, both from the business perspective as well as the development perspective.

There has been a lot of conversation in the agile community around User Stories and use of Story Points to size the product backlog items. What is often lost when teams adopt this technique is the value of team heuristics, as in team experience and the importance of relative sizing.  These put together and followed with some discipline allow the team with the ability to forecast – as in over discrete periods of time, sprints,  express an ever accurate answer to the questions:

How much by this date?


All this by when?

If no one is asking these types of questions at the end of each sprint then you may be in danger of falling into the cargo cult scrum trap, as in following a ritual of sizing product backlog items for ritual sake.

So what does heuristics really mean?

In a nutshell heuristics refers to experience based techniques for problem solving, learning and discovery, one which is good enough approach to finding an answer, where the perfect answer is not knowable or would be too expensive to learn.

So, if you are familiar with how most sciences work, you have probably encountered the use of  heuristics before. For instance, rather than predicting exact ratios of chemicals for a reaction, chemists use heuristics as guidelines in predicting how various chemicals will react. Similarly in engineering for instance aircraft designers use heuristics by considering coefficients of lift and drag to point them in the right direction, with the design empirically refined based on experimental evidence.

In essence to answer either of the questions stated above there is a heuristic alternative to the careful reasoning that occurs in the long cycles of phased approach in gathering requirements, analysis, design, development and test. This heuristic alternative works well for estimation and this is in spite of sometimes serious errors. The key is to ensure the errors are bounded across short time intervals, with frequent pauses assess the outcomes and inform what to do next. Of course Scrum provides for a natural cycle of pauses at the end of each timebox, where the team can take stock of the outcomes as well as assess the steps the team actually took vs. assumed what they took, yes essentially these being the sprint review and end-of-sprint team retrospective.

First Order Estimation

So what is the first order of estimation, well it is something we all do so naturally and effortlessly when it comes to driving a car to riding a bike to walking in a busy mall, else surely we would be running into each other most of the times. I mean when is the last time you got out a measure tape when changing lanes on a freeway or overtaking to ensure you have the most accurate measurement in distance or speed.

In essence the first order estimation I refer to is a relative measure, in this case of work items (user stories) to one another.  To me it is similar to coefficients of lift and drag considered in aircraft or even car design. Its just that in this case these estimates can be now be thought of as being the teams coefficients, one that corresponds to the team that is going to do the work based on their perspective for product backlog items as opposed to anyone elses.

Team’s coefficients

There are teams that only look at their team coefficients, user story points, when planning a sprint. This may well be all that is needed for planning, but in truth this is only the case for a teams that have been together for a long time, have experience of working with each other and have established team heuristics, their rules of thumb.

Teams that are new or new to working as a scrum team often miss out the need to assess the team capacity at a more granular level of planning, one that breaks a product backlog item (user story) into actual tasks that need to be performed in order to get to done!, before making team commitments. So it is best for a team to be mindful and disciplined towards developing the team heuristics and continued reliance on wisdom of the crowd to decipher difficult problems that includes estimation.

To do this start with having a stable team one that takes a disciplined approach in their scrum ritual meetings during the sprint. This includes when refining backlog items and/or sizing using story points to when planning out by defining tasks along with task level time estimates as this is what will help shape the teams commitment to the plan that appears in the form of a sprint backlog.


Daniel Kahneman, in his book Thinking, Fast and Slow, points to how judgement happens, and while it is a complex function of the brain what he points to is what Psychologist have to offer based on their observations supported by what Neurologist tell us about functioning parts of the brain.  In essence we have evolved to with two modes of thinking, called System 1 and System 2 as coined by psychologist Keith Stanovich and Richard West.

Where System 1, evolutionary the oldest, the part that is responsible for fight or flight and ingrained to our survival instinct, operates continuously and generates assessments of various  aspects of the situation with little or no effort. This basic assessments plays a vital role in intuitive judgement, as this routinely substitutes the more difficult question being asked of by System 2, the essence of heuristics.

Where as System 2 thinking considers, only if it must, the difficult to answer questions the one that System 1 doesn’t readily offer an answers to, and it triggers many other computations including basic assessments acting as a mental shotgun according to Kahneman. He points out the word heuristics comes from the same root word as does the word eureka, and is technically defined as a simple procedure that helps find adequate, though imperfect answers, to difficult questions.

Continue reading…

Talk to your customers

I have heard something multiple times this week, something that has me a bit concerned. The gist of the sentiment is something like this: “Oh, we discourage the developers from talking to customers; we don’t want them to be distracted from their work or to build a bunch of stuff that’s not in the plan”.

If you are working in an agile environment, this sentiment is outdated and harmful. We want developers to understand the customers and have empathy for them, and there is no substitute for direct interaction for building that understanding.Let me start by discussing the agile mindset regarding developer-customer interaction, then address the concerns expressed in the statement.

Cross Functional Teams

Agile, and specifically scrum, relies heavily on the idea that cross functional teams build better stuff. While product managers, sales people, and similar roles have responsibility for understanding the customer problem space and communicating it to developers, and agile teams typically have a Product Owner for a similar purpose, agile teams see that expertise as a part of their team, not a separate group. The most effective development teams try to learn as much about the customer problem space as possible. They make multiple small decisions every day about how to solve customer problems. Requiring all knowledge about those problems to be siloed in one person or group, and separating that group from the team creates an unnecessary bottleneck to the system. Once developers understand the Why of what they are developing, they become much more engaged, championing solutions that they think will best help their users.


Great products emerge from experimenting in the overlap between the customer problem space and the technical possibility space. Developers know the second space well, but can only know the first space through experience either as an actual customer or through talking to customers. In my experience, great products are rarely built without the developers having a good idea of how their customers think, and more importantly, empathy for their problems. Chip and Dan Heath give a great example of this in their book Switch. They describe a Microsoft team full of brilliant developers. They were certain they were writing brilliant software, but when the usability group tested it with users, six out of 10 customers couldn’t figure out how to use the new features. When they told the programmers, their response was, “Where did you find six dumb people?” To increase empathy, Microsoft brought the programmers into a usability-testing lab and put them behind a two-way mirror. When the programmers watched a real customer struggle with the software they designed, the programmers immediately started thinking about ways of changing it. They were developing empathy for the users, and instead of contempt for their ineptitude, they developed an intrinsic desire to improve the software to better meet the needs of the customers.

But what about those concerns?

“…we don’t want them to be distracted from their work…”

In his book Radical Management, Steve Denning describes a shift in the way that we describe the high level goals of everyone at a company. He proposes that the primary goal of every employee is to “Delight Customers”, and that companies should set measurable goals for the company, executives, and employees related to this purpose. In this light, the idea that a developer’s work can be summarized as “writing code” feels almost insulting. Great software teams tend to spend the vast majority of their time figuring out what problems their users are facing, potential solutions to those problems, and the best technical approach to solving those problems. A small percentage of their time is spent actually typing code. In this environment, “their work” is not just writing code, but delighting customers.

“…we don’t want them to build a bunch of stuff that’s not in the plan…”

This one’s pretty easy to address in an agile environment. One of the simple rules of scrum is this: “if it’s not in the product backlog, we don’t work on it”. This provides transparency to the system.

Another potential concern:

“…developers will promise customers stuff that we can’t deliver…”

Sales people have been doing this for decades, so this isn’t much different <grin>. At least if developers promise something, they get to experience a direct consequence of their action, so the behavior is likely to improve.

So get out of the building, talk to customers, find out what’s driving them crazy. Scrum says that developers should spend 10% of their time on forward looking backlog refinement. What if they spent an additional 10% of their time talking to customers? Would we have a higher chance of delighting customers? It’s an interesting hypothesis. Anyone care to test it?