Tag Archives: Iteration

Why user stories make sense?

User story is a popular mechanism used by most agile methodologies to communicate user requirements. Actually, this is only partially true. User stories are meant to be a placeholder to initiate an early conversation between the product owner and the team on key hypotheses so that a quick validation of them could be done to refine/confirm/reject our understanding of what the customer really wants. To that end, user stories are not anything like the requirements of yesterday – they are not even remotely meant to be complete/comprehensive and so on. 

The reason user stories (and not ‘well-formed’ requirements, if that is ever possible) makes sense is because we human beings are not experts in following the written word, and are likely to misinterpret requirements even when they are explicitly written down, especially when the communication is a one-time event and not an ongoing process. (if you don’t believe this, just visit this interesting site http://www.cakewrecks.com/ that celebrates real-life examples of how something as simple as icing on the cake can go horribly wrong despite really simple and absolutely clear instructions!). And we are talking about building complex mission-critical systems that must operate 24/7 with top speed and efficiency. If only the written word could be consistently understood by the receiver as intended by its author… 

On the other hand, if there is a continuous two-way dialog between the product owner and the agile team, such purposeful brevity leads to curiosity which then leads to a constantly improving and better shared understanding that refines as the product gets developed incrementally and gets periodic user feedback. 

User stories reflect the reality that we might not have 100% clarity about the requirements on day one, but with constant dialog, we might be able to improve our shared understanding of customer's wants and needs.

User stories reflect the reality that we might not have 100% clarity about the requirements on day one, but with constant dialog, we might be able to improve our shared understanding of customer’s wants and needs.

The key benefit of user stories is that instead of waiting for weeks (even months!) to get a fully-bloated and rather unprioritized PRD which is supposed to have fully-baked requirements while the development team sits idle all this time, is that identifying highest priority user stories and using them  to develop a prioritized product backlog allows the teams to get started much earlier and start developing features which could then be put out in front of customers to get real feedback (as opposed to individual ‘opinions’ that might/not best guide us in an uncertain environment). This is especially important because in the past, when the world was little less complex and much more underserved. I purposefully use this term ‘underserved’ because it is not that people have suddenly become much more demanding about what they like or not, but were just told there were exactly three carmakers to choose from, or just two operating systems to choose from, and so on. However, with rapid advancement of computing paradigms and constantly lowering cost of ubiquitous communication devices, they suddenly have the opportunity to demand what they want, and hence classical ‘forecast’ models of requirements elicitation, design or production (at least in the manufacturing sense) don’t work so effectively as much as the newer ‘feedback’ driven models that allow for developing key hypotheses (and not hard requirements carved in stone) which could then be quickly and cheaply delivered as ‘done’ features so that customers could tell us if they like them or not. Based on such valuable customer feedback, the team could iterate to either refine the feature, or to pivot, as the case might be. In the past, this might take the entire product gestation cycle, by which time, many, if not most, things might have undergone significant changes, and the entire development costs being sunk by that time, not to mention complete loss of any window of opportunity.

As Facebook says – Done is better than perfect. User stories allows developing a small slice of the product without really perfecting the entire product, but facilitates the process of validated learning that eventually helps develop a product with much higher chances of meeting customer needs.

In today’s world, you probably might not have the luxury of having investors wait multiple years for an exit, or customer waiting several quarters for a perfect product when the competition is willing to serve them faster (even letting them lay their hands on an earlier version and give feedback thus making customers a co-creator of the product), or employees working month after month without getting any meaningful feedback from customers. And we know that absence of any feedback eventually leads to erosion of trust. Incremental product development could help you bridge such trust deficit by delivering highest value to customers early and periodically, and user stories might help you get your project a quickstart.

So you think you are a top-notch Project Manager ?

Building Pyramids is one of the most common examples and metaphors in project management, and should I also add, perhaps one that is almost always discussed about by people who have practically no knowledge of construction engineering, let alone experience in building a pyramid (after all, I don’t know too many people who can claim to have built a pyramid). There is always a classic problem of what is the right way to build a pyramid: if you go by the much-maligned and clearly fallen out of favor ‘waterfall’ way, what happens if the King dies midway and the Pyramid is still unusable ? Worse, what if the King comes half-way down the project and sees bottom half of the pyramid and remains unimpressed with the sight and either wants to change the project specs, or worse, wants to stop the funding because he is not happy with what he is getting. OK, you want to build the top first. What if the King finds the explanation of building the Pyramid top-down funny (remember, there is no past precedence of your idea, and you might be ridiculed for your ideas – it is 2500 BC, after all) and all he sees on the ground is a miniature Pyramid ? What happens if a rival King starts constructing a bigger pyramid – can you now change the designs and make your pyramid bigger than the rival King’s ? Surely, there are obvious limiations of this model.

The other alternative is building it the ‘Agile’ way - starting with a miniature fully-functional pyramid and then incrementally building it inside-out. Theoretically, it sounds like the right thing to do – if and when King comes for inspection (and you can always count on that !), he always sees a ‘complete product’ albeit a miniature one. If he is impressed by the ‘plan’, he might release more funds and theoretically, the construction could go on perpetually, i.e., until when the King one days breathes his last. That day, right after the next ‘iteration’, his body could be laid in eternal peace in the majestic pyramid. However, there is a major problem with using Pyramid metaphor to justify Agile way of construction. Most of us who are simply ignorant about construction engineering treat the problem as building a Lego Pyramid – there is only the civil component of construction that is considered in any well-meaning debate. What about plumbing, what about electricity (ok, there was no electricity those days but you surely need air and light ducts to serve the purposes that electricity would have served otherwise), what about the state of technology that was available back then, what about stairways, what about interiors, and so on. Can all these be built inside-out ? Construction engineering might not entirely agree with building a Pyramid incrementally.

Well, there are critics on both sides of the thick and high wall that separates these two worlds (with some of them, perhaps, perched atop the wall as well) and there seem to be strong emotional views about which is better and why. In this post, I will not add anymore fuel to fire, but share an interesting thing that I came across. Chances are, irrespective of what camp you belong to, you will find this simluation exercise interesting, and guess what, you actually get to build a pyramid ! There is this great game on BBC site that tests how good a project manager you are – by playing a game to build The Great Pyramid ! Here is what the text reads:

Journey back four and a half thousand years to Egypt’s Old Kingdom, to the Pyramid Age.

As the vizier, or head of state, you are about to undertake the most important project of your career – the building of the king’s pyramid.

To succeed in this task, you must be a good all-rounder. Not only should you be able to motivate your workforce, but you must have good observational skills and the ability to steer a barge up the Nile, avoiding hippos and crocodiles.

Have you got what it takes to be a pyramid builder?

What I specially liked about the project is that it places emphasis on just about everything you require as a project manager to complete you project successfully – domain skills, planning and scheduling, executing skills and the most important of them all – the people issues, like what type of people to hire (and how many) and how to determine the reward strategy. This is not just a drawing board game – you actually get to ‘execute’ project (at least I got to execute a part of it, and I guess the game might allow you to do more if you pass the first stage).

If this sounds like fun, click here to take the Pyramid Challenge.

PS: I took it once and lost the game. My ‘project’ failed miserably :(. Hmmmm….