A question, “What exactly is Agile?”, keeps troubling people.
They either make reference to the manifesto or map it with Scrum and then get circled in its events and practices.
Recently this question popped up again when one of my friends asked:
Question: I work for a large software services company. Sometimes I feel that different people have a different understanding of Agile, including me and my customer. Many things which I find sensible to do in my context seem to be not allowed by Agile police. I hear lots of different variations of Agile from people.
So when I meet a person, he may say this is how we should work in an Agile project. Another person may say it contrary to what earlier one said. I get introduced to different coaches in my ongoing projects and I get confused with their interpretations. People also get stuck with dogmatism around a framework or with an Agile project management tool. What exactly is the focus of Agile?
Though Agile movement started as a better way of developing software, it has moved beyond software development (e.g. Scrum framework is no more just for developing softwares).
Agility has evolved into a way of thinking, permeated to organizational work culture, experimentations, better ways of doing business, product development and servicing customers.
It started in the context of and in reaction to the Waterfall approach initially. Now it doesn’t have anything specific to compare to. It’s ever evolving.
That’s the reason, people took the Agile manifesto as the foundation for Agile movement, it didn’t remain constraint in making further improvements ever. In the last few years, people have evolved and embraced Modern Agile concepts, Lean thinking, Lean Startup and Design Thinking approaches for the same reason.
‘agile’ is an ordinary word in English. It means “able to move quickly and easily” (online dictionary), with an *emphasis on changing direction*.
So essentially ‘agile’ is the ability to create and respond to change in order to succeed in an uncertain and turbulent environment.
From the software development perspective, in the late 1990’s, several software development frameworks emphasized close collaboration between the development team and business stakeholders; frequent delivery of business value, self-organizing teams; and smart ways to craft, confirm, and deliver code.
In early 2001, 17 software development practitioners gathered in Utah to discuss their shared ideas and various approaches to software development.
The term “Agile” (respond to change in order to succeed in an uncertain and turbulent environment) was chosen to match the sense of the way they wanted to work. Once they had the word in place, they had to decide what it meant to them for the purpose of writing software. They chose 4 values to centre themselves in the world while working.
Individuals and interactions over processes and tools
Working software (or product, or more generally, accurate feedback) over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
They also added 12 principles.
In total, from agile manifesto standpoint, agile is all about:
Can we move and change direction quickly and easily?
Do we center ourselves on these four values and principles?
Sometimes the question comes – there may be innumerable practices suited to a context or may get evolved. How to ensure if those are acceptable in Agile methods?
To that, I see Agile methods are based on common sense. As long as a method or practice is in line of Agile values and principles, you are fine. For instance, once we realized that distributed retrospective along with customer team was not helping us in solving local problems, we decided to have local retrospective as well and it worked pretty well for us. Similarly, though the definition of Ready is not essential in Scrum guide but we found it tremendously useful while working in distributed teams with opposite time zones. All these things made sense to us and we continued.
The Essence of Agile
Many people interpret agile to be fast but that’s a myth. The focus has been to deliver the working product in incremental and iterative fashion but that doesn’t translate into ‘fast’.
After working in Agile methods for many years, I realized that self-organization, inspect and adapt, continuous improvement and feedback as fundamental aspects of the manifesto.
Collaborative practices like pair programming, swarming or mobbing are the stepping stones towards self-organization. In many orgs or teams, people continue focusing on everything else but “self-organization and feedback”.
People continue working solo in a team, resulting in minimal collaboration and no self-organization. They do that in order to have 100% utilization (coming from the traditional mindset).
Feedback and Maximum Learning
Actual feedback and maximum learning comes from users and not from representatives of the users. That’s the reason, many organizations are deploying multiple times a day to receive the feedback through Continuous Delivery and DevOps. From a software development perspective, multiple deployments in a day to production is a huge paradigm shift.
So, keep a good amount of time in designing, create MVP, deploy, grab feedback and iterate again. That’s especially true when you are working on creating complex products in unknown terrain.
It’s important to note that it’s essential to spend time in thinking, designing and architecting before building MVP. Watts Humphry has said it already: “If design time is less than coding time: red light!”. If we preflect to see what we are going to do, we can avoid doing unnecessary features.
Jeff Sutherland had on occasion spent years building a backlog before building a system. You can deliver your first financial system that meets regulatory requirements only after months of infrastructure.
Irrespective of how much pre-work goes, without validation from users, our definition of “viable” is a guess. That validation may happen before as well through design thinking and getting feedback on minimum viable pretotypes. That way we try to minimize waste as much as possible.
We keep facing real world challenges in Agile world. For some challenges, the rule-books provide straightforward answers but empirical evidences show the contrary. That’s where Tim steps in and helps us in understanding the nuances and demystifying the problem space.
In recent past, we have had many such conversations with Tim on our Slack group “Agile Commune”. All those are full of insights and very helpful. We’re making some of them public as part of “In Conversation with Tim Ottinger Series“. Looking forward for your comments and experiences on these topics.
Shrikant: Hi Tim. The tools (like Scrum, Kanban, TOC, XP etc) are to solve business problems. They themselves are not the goal. How do you define agility?
Tim: To me “Agility is a means to an end, not an end unto itself.”
I would say that agility is a process goal, not a business goal.
To be able to change direction at the drop of a hat is powerful — provided your organization plans to do some pivoting.
Agile methods have the goal of creating some agility in the business, or at least the conditions making it possible.
Some methods are better at using agility than others.
But remember that a skateboard is more agile than a freight train, but a freight train is bigger and faster than a skateboard.
Be sure you know what you want.
Shrikant: Do you think agile maturity should be the goal for teams?
Tim: Agile maturity is a funny idea. A lot of people use it in reference to the CMMI maturity model, which I think is a poor model for agility.
In the CMMI maturity model, you start with conformity. Everything starts to be processed, documented, standardized, automated. Then you become consistent and more fully automated to become “consistent”, and then processes are measured and controlled.
And only then, according to the model, are you ready to focus on process improvement. But by then every person and machine has settled into a process that has significant investment and inertia.
In other words, you can start to make changes after you have created a system to resist those changes.
These people look for conformance to a known agile framework or methodology as “agile maturity.” I don’t think it is reasonable to define agile maturity as the absence of agility. Conformance to a process is not a useful definition of agile maturity.
But agile fluency is perhaps the better model here. Being fluent is the ability to move with grace and without a lot of inhibition toward a goal. As an analogy: when you speak in the language you use best, you are fluent and it is effortless. When you speak in one you have just learned, you aren’t so fluent so you struggle to translate the new language to the old one.
If I were going to run parkour (the activity or sport of moving rapidly through an area, negotiating obstacles by running, leaping, vaulting, and climbing), I probably want to work on strength, endurance, burst speed, leg muscles, etc.
But since I’m not going to run parkour, I don’t need the same level of agility and strength.
Is a greater degree of agility important for a parkour runner? Yes. But their goal is to quickly and impressively navigate obstacles. Agility is a crucial element in doing that, but they aren’t doing parkour so that they can be agile, they’re becoming more agile so that they can do parkour.
Coming back to business world, maybe you don’t know what your business goals will be in 5 years, but you know that you have got to respond to a fast-changing market.
In that case, investing in agility might be the most important thing you can do.
If your company’s revenue stream comes from it being consistent, unchanging, compliant to road-maps, reliable, and stable, then maybe you don’t bother being agile. Maybe the CMMI kind of “maturity” makes sense if there is no intention to change.
Shrikant: To summarize, are you saying that agility should be the goal and not maturity? Also is it fair to combine both and have a term called agility maturity or it’s better to focus on agility only (you are either there or still trying to)?
Tim: Yes, more agility in order to produce valuable software better.
There is a risk to combining “agile” and “maturity”, since a lot of people see the words as opposites.
I think it is fair to also talk about how far one has come with agility, which I guess could be seen as a different kind of ‘agile maturity.’ For instance, there was a recent article that characterized agile maturity as a matter of how often you can deliver working code.
Modern agile has 4 guiding principles, one of which is “deliver value continuously.” The article described delivering software continuously. Since software features create value, that kind of maturity approximates a modern agile guiding principle in a limited way.
We don’t have a “modern agile maturity model” and probably won’t, but if we did, I would like to see it based on measuring how an organization seeks to maximize their effectiveness.
I don’t want to see a maturity model be based on how well one sticks to a particular process or framework.
Shrikant: I believe just doing the motion or ceremonies should not be the goal of agility. What’s your take?
The ceremonies would never be the goal. Having planning meetings, standups, and retros has almost nothing to do with agility.
When you say “agility” do you mean “the ceremonies and titles of agile methods”? Because I certainly do not.
For instance, you can do scrum for five years and never be agile. A number of don’t collect feedback, don’t act on it if they do, and use scrum mechanisms to pressure people to work harder to fulfill some long-term goals with two-week milestones.
I can’t recognize anything resembling agility in that model. It sounds a lot more like a sweatshop.
I think that someday we will outgrow the ceremonies and processes. They aren’t the core of agility anyway. I don’t think we’ll miss them.
Shrikant: Is there any reference or help in defining the agility?
Tim: The Modern Agile values define agility. The manifesto does too (especially the 12 principles).
The first line of the agile manifesto says “We are finding better ways of developing software by doing it and helping others do it.”
This is not past tense. Agile is a search. Any process we currently use to achieve “agility” is temporary, to be tolerated until we find a simpler, faster, more certain way to get great results.
Compare it to google search. If you go to the google web page, you don’t see google search. You see a box where you can send google search a parameter. When you complete a search, you see the first N results of the search, you don’t see the search.
Those results are not google search. They are the temporary artifacts of having used google search.
This describes agile frameworks/methods also. They are the temporary artifacts of having used agility. Standardizing on the output doesn’t replace the search algorithm.
Any specific agile process isn’t “agility.”
A process is just a process. And as we know, processes and tools take a back seat in agile software development.
I would like “agile maturity” as a term if maturity was measured by the number of useful, simplifying innovations that come out of an organization that engages in this constant search for better ways of making software.
Learning and sharing better (more lightweight) ways of working is the core agile mission. Is there a maturity model that promotes that ideal? If there is, then I will get behind it.
About Tim Tim is a programmer, author, trainer and globally recognized coach with over 35 years of real software development experience.
Tim is an active speaker and author with writing credits in Clean Code, Pragmatic Bookshelf magazine, the C++ Report, Software Quality Connection, and other publications over the years. He is the originator and co-author of Agile In A Flash.
He continues his work helping teams around the world find better ways of working along with an impressive constellation of Modern Agilists at Industrial Logic.
‘agile’ is an ordinary word in English. It means “able to move quickly and easily” (online dictionary), with an emphasis on changing direction.
So essentially ‘agile’ is the ability to create and respond to change in order to succeed in an uncertain and turbulent environment.
Recently I observed that real world traffic and Google Maps can help a lot in explaining the concept of agility. This post is all about joining the dots.
Driving in a real world traffic is not straightforward. Time taken to cover a distance depends on traffic jams, weather conditions and other unknowns.
When someone asks how much time it will take to cover a specific distance in Delhi traffic for instance, only true answer is a range of time, say anything between 30 minutes to 1-1/2 hours.
Moving back to software world, when someone asks a similar question, e.g. provide an estimate for a complex software project, there can’t be a single estimate but will be a range of estimates, i.e. anything between ideal scenario and the worst case scenario.
Continuous Inspect and Adapt with Google Maps
It’s evident that the plan driven approach doesn’t work while driving to an unknown terrain.
In order to handle these unknowns better, in recent times, we have started relying on Google Maps which helps in providing the best available route considering existing traffic conditions. That helps in getting an initial shot to reach to a destination.
As we start driving, Google Maps keeps on collecting the real-time road-traffic information and keeps analysing that data. As and when it finds a better route considering existing road traffic conditions, it provides the rerouting option.
In Scrum as well, Daily Scrum is an “Inspect and Adapt” opportunity and is all about daily replanning. As part of Daily Scrum you replan the sprint every day considering what got changed in last 24 hours.
For example, yesterday, a team started swarming on a user story. During the day, team discovered additional complexities in finishing the work. Based on this emerged complexity, as part of today’s Daily Scrum, team decided to add few more people to join the swarm.
Remember, Daily Scrum is not just about sharing updates but more importantly about taking actions on emerged challenges in order to move towards sprint goal.
Similarly it’ll be a mistake consider Sprint Review all about demo. Apart from many other important aspects, Sprint Review provides an “Inspect and Adapt” opportunity for Scrum team to make changes in overarching product direction based the feedback received on the deployed features.
Travel and Pivot
Sometimes we travel with an intention of having dinner to a certain restaurant we haven’t visited before. However based on what we see (empiricism), we change the plan and may move to an altogether different direction or location. Instead of eating Indian, we could finally opt for eating Chinese.
Something similar happens while looking for product-market fit as we may end up pivoting multiple times before we actually see the product-market fit based on market conditions, feedback and analytics.
This is a story of a small IT service company in India with a capacity of 80-100 people. The key USP of the company was its focus on flat hierarchy, extreme programming culture, getting great people onboard, technology innovation, thought-leadership and encourage people to become authority in their respective field.
Flat hierarchy for the simple reason — it could be one of the biggest blocker for empowerment, innovation and decision-making in a startup. So it was quite common to see a senior developer pair programming with a newbie.
By having flat roles you can build a self-organized and autonomous team, which then could take its own decisions.
Here are some of the snapshots of what we were looking for.
Employees were encouraged to consider organisation like a clean slate. They could write on it whatever they want as long as it gelled with company’s values, brought improvement in status quo and a group of colleagues were convinced about the idea.
If anybody felt uncomfortable the way things worked in the organization, she could initiate a discussion in the company around the change and if idea makes sense, it would get implemented.
Considering all mentioned above, it was not a surprise anymore to see a big focus on the following mantra in the company.
Scratch your own itch. If it’s itching you hard, fix it.
The essence is — people were encouraged to come up with solutions instead of just coming up with list of problems. Everybody in the company was considered an equal partner in improving things.
The result was — anybody could start any initiative, which he/she thinks to be beneficial for the organization. Senior management helped in shaping the ideas. However people themselves had to sell their ideas to fellow colleagues and garner support.
Bringing this kind of cultural change was a huge challenge considering inherent hierarchical culture and existing industry environment. A person joining the company used to get a huge cultural shock in the beginning.
To provide some impetus and catalyst to these cultural changes, we started promoting some activities like blog writing, record technical videos and publish them, shaping communities of practice around various emerging Software technologies, participating as speakers in various technical and Agile conferences.
The medium of the communication of these exchanges was through email groups and face to face interactions. People were encouraged to come forward and lead these initiatives.
There were some lighter initiatives too like guitar, LAN games etc which were necessary to break the monotony of the work-place.
That gave a wholesome feeling to people, as they stopped looking office as just a workplace. People could give shape to their passion or interests there.
Initially everything worked as expected. However after some time, to my surprise, steam began to die down. Many people backed out when it came to do some work, though they expressed their keen interest initially.
Another important fact was — only few selected people were participating in most of the activities. Just 5–10 out of 70-80 people was not an encouraging number.
That brought a bit of frustration as it was difficult to understand what went wrong. Though I tried understanding things like what exactly motivate people and experimented with those ideas but again that didn’t bring any significant result.
One fine day, I was talking to a colleague whom I thought could bring a lot on the table. However surprisingly, he wasn’t participating in any org level initiative.
While having conversation with him, I expressed my frustrations and asked for his opinion. I said, “Rajesh, what are your views on current initiatives going on in the organization. Also what do think why people are not responding to them?”
In response whatever he told, surprised me.
He said, “Why do you expect people to respond? There are many people who are not that outgoing in nature and feel shy to come out of their shell. Also many may not be interested in the initiatives you are talking about but may be interested in others which don’t exist as of now. Why don’t you talk to the people and understand what really motivates them instead of just focusing on what’s important to the organization?”
Honestly I never thought about it before and it opened my eyes. In order to implement this new revelation I changed the approach completely.
For the moment I completely set aside the organizational goals. The focus now was to understand people and their passions.
The idea was great but honestly it I had absolutely no clue how to execute.
It’s comparatively simpler to find what people want. However other bit — what exactly people would be interested in doing is not that simple to understand. That might relate to their passions.
However, many a times, even people themselves are not aware what they are passionate about. They may tell you things based on context or who is sitting in front of them but in that process they might fake the reality.
Also in many cases, passion may not directly translate into achievements. In those cases, people try to downplay those aspects of their personality.
On experimental basis, I started having open-ended informal conversations with people on individual basis. The idea was to know a little bit more than just their professional persona. Also, it was important to make people comfortable in their own space.
Those conversations had hidden goals and focused on to identify:
Subjects they are passionate about. Things they really enjoy doing. Things they would like to do again and again.
While having these conversations, I realized one has to make conscious effort in discovering people’s passions as they may not be aware about them.
That’s why conversations were full of questions related to their personal and social life, their interests, things they like and dislike. Some questions were also related to their college or school life, a time when most of the people do what interests them the most.
During those conversations, I found that many people had lost their vigor and zeal in maintaining their interests because of changed priorities in their life. But rediscovering those lost interests in itself was very enriching experience.
For instance, one of the colleagues did a research software project to transform the voice of a person into someone else’s. He also created a software project, which could convert a human skull into some recognizable human face.
Yet when I looked back, I realized he never got any right opportunity during his last 1 year in the company. Also nobody ever knew about his hidden talents.
Similarly another colleague was very interested in organizing events in college and had already organized mammoth college event single-handedly. Yet another colleague was an editor of college magazine and was very good at writing.
Based on these conversations, I discovered people with many sorts of interests.
All it required was to synergize their passions and energies into bigger organization level goals.
Organization is like a soccer team
One of the biggest mistakes for any organization is their focus on only creating heroes – players who could play at the front and score goals.
In many companies, management also encourages people to become heroes.
However the truth and the reality are way different.
You get fruit from a tree having a solid foundation. Similarly a 100-stories building can’t sustain without having strong foundation.
Organisation is like a soccer team. In soccer, win is not only dependent on scored goals but also on the saved goals. Soccer or any team game is incomplete without the collaboration of forwards, midfielders and defenders.
Scoring a goal is also a team-effort, which unfortunately is perceived as just forward’s effort in many organizations.
The reality is – defenders and midfielders lay the foundation based on which forwards score goals.
In an organization, it’s useless to push everybody to become forwards or heroes (key innovators, conference speakers etc) as everyone has their own strengths and weaknesses.
Pushing people to do something towards perceived organizational goals may not always work.
This was one of the key ideas we tried to introduce in the company culture through the exercise of identifying or discovering passions.
Passion Driven Work and Organizational Goals
The exercise of identifying passions in many ways was to recognize a great self-organized energy pool.
People generally love to do stuff they are passionate about.
Leadership and people can now collaborate in marrying the passions to the right opportunities org wide.
Organization needs everyone. Not only forwards but midfielders and defenders as well.
That’s the basic foundation of Passion driven work.
Based on received inputs from colleagues, we started aligning their interests towards the long-term organizational goals. After some time we started getting sustainable and dramatic results.
At one point, people writing on corporate technical blog were around 5–10% of total number of people. That changed to around 50–60% people in the organization.
Initially that happened because of the interest shown by truly interested people about it and then because of healthy competition among the colleagues.
We started finding the involvement of people in various activities like hiring improvement initiative, building technology guilds, multimedia and marketing, software design competition, organizing events, innovation and speaking in conferences.
More teams I work with, I face almost similar kind of challenge wherein team members want to remain confined to their roles. They continue to work solo. No pair programming, swarming or mobbing.
Because their skill sets don’t match. One such team have two iOS developers, 2 pythons developers and one tester. They can divide the PBIs into subtasks but they’ll continue to work solo as their skills don’t match.
It seemed like a valid point to me at first.
But then I thought a little deeper. Why exactly do we have developer or tester role to begin with? Aren’t they actually skills?
Considering myself a developer, do I need to be a developer only throughout my life? Can’t I test as well? Of course I can.
Similarly if I am a Python or a backend developer, nobody really constrain me to remain a backend developer throughout my life.
But then these roles seem to be embedded in our mindset. Ever thought why?
You see, traditional waterfall had well defined phases and so brought out well defined roles as well. People with these roles had enough work for themselves in different phases.
But then in Scrum, you don’t work like Waterfall, i.e. in phases. You do everything all the time. Testing is not the last line of defence anymore. Everybody tests and should test. Quality becomes a primary goal from day 1 for everyone.
Testing also is a skill which everyone can learn. Similarly backend developers can also learn how to develop in front-end. Again no big deal these days.
Then why do we have Waterfall roles so deep-rooted in our mindset?
Although, from Scrum standpoint, it is sufficient for a team to have all the talent necessary to deliver Done functionality, shouldn’t we move beyond?
TPS moved from 1 person per machine to 1 person handling multiple machines. For further improvement, they moved towards work cell and one-piece flow concepts.
Why should We Even Care?
Some readers may still be confused, why am I so hell bent in having multiple skills in a person.
There are many reasons. If a team has 2 front-end developers and 3 backend developers, a PO must find work for everyone, no matter what.
But that creates trouble from business standpoint for cases where PO requires 4 front-end developers in a sprint.
He has to survive with 2 front-end developers only or has to hire more. At the same time, he should be able to create enough work for 3 backend developers, otherwise they’ll sit idle.
Another reason is – TPS researches have established that the best possible way to do work is through One Piece Flow requiring minimal or no handoffs. That helps in saving a lot of waste and is lot more efficient as well.
How Does A Learning Person Look Like?
Throughout past few years, there has been a lot of attention on shaping T shaped person.
T-shaped individual has a specialty (backend, frontend, or a particular technology stack) but is comfortable doing a wide range of development work and/or product management, design thinking etc.
Teams built with T-shaped individuals tend to adapt to the challenges ahead easier.
The idea is – in a team, for each core competency, there should be one expert and one alternate. The alternate needs only to be competent as a developer.
John’s key competency is Spring but he is competent in AngularJS as well. He is hardly an expert in AngularJS. He has to have a book in hand if he’s going to do anything adventurous. But he is a learning person. Such adaptability is at the heart of agile development.
John knows nothing about ReactJS or about 100 other of the new cute technologies out there. But if you were to put him on a project using ReactJS, he could become competent in couple of weeks and proficient in couple of months. A learning person would accommodate the need.
That’s a big mindset shift compared to existing “I am Java developer or a front-end or a backend developer”, siloed mindset.
T-shaping works great within a profession. For instance, it’s easy for a developer to help a tester or for a Java developer to learn Python.
However in a team of an Electrical Engineer, a Mechanical Engineer, a physicist, a software person, it doesn’t make sense teaching the programmer enough about physics to be able to know the flow equations. If such a team went looking for T-shaped individuals, they would need forever to hire a team.
How People Become T-Shaped in a Scrum team?
First and foremost, for a team it’s important to be truly cross-functional. That way, the team covers its bases and is able to work on and create end-to-end functionality.
The second step is to do enough cross-training to get to the expert / standby position. This is a risk mitigation strategy. If you lose a team member, either permanently or temporarily, it doesn’t stop the team dead in its tracks.
Also, if a team is supposed to work together for 6 months or for a year, it certainly makes sense to learn the rest as secondary skills. This works just because we are still talking about software development. It will not work for a software developer and a construction engineer.
In order to learn secondary skills, people have been using online hands-on courses like PluralSight or Udemy to get the jump start on the new technologies. The quality of many such courses is also pretty good.
With this base and a good reference book or resources in hand, people learn further through pair programming with fellow developers. In my experience, pair programming works really well to learn new stuff.
Some orgs ask the people on bench OR the technology experts to create a full day hands-on workshop for colleagues.
As a third step, it is important to deepen individuals’ knowledge in what they do know. These folks can make snap judgements, and snap judgements are extremely valuable because they avoid wasting time — and they’re usually right.
How should we Hire?
We should hire on the basis of a person’s ability to learn new stuff. The main contributing factors are aptitude for learning and attitude. Secondary factors include experience (decades dealing with systems) and breadth of exposure to different projects. This contributes to people’s ability to integrate and generalize.
I sincerely feel that we should move beyond the Waterfall mindset of categorising roles and forming teams with mini silos wherever possible. It’s enough to have a role called team-member who may have multiple skills under her belt.
The last word relates to professionalism. Software is a specialization. If people count themselves “software engineers” or programmers because they stand on one given technology, then they are not, in my opinion, professionals.
If a software person is lacking in database, or testing, or Ruby, or computational complexity, they haven’t yet attained the level of being a professional: they’re still just a hacker.
This piece wouldn’t have been possible without kind inputs from James Coplien.
One of the popular mechanisms to estimate story points as a team is planning poker exercise.
It’s an awesome technique but it may become a challenge for some teams. For instance, a team estimates story points separately as developers and testers. Later, they add up those points to arrive at resultant estimates.
Some teams get into endless discussions to ascertain if the estimate should have been 2 or 3, 5 or 8 or maybe 7.
It looks like, the primary goal of planning poker exercise is to arrive at the correct estimate.
But that’s not the point!
Before we understand why, let’s know a bit more about user-stories.
What are user stories?
A user-story doesn’t become user-story just because you write them in a particular format (“As a…I want…so that”). It’s also not about to write them on 4×6 index cards or placing them in tools like Jira.
User stories are all about “Requirement by Collaboration”. Hand-overs between business stakeholders and development team or even within the team are replaced by frequent involvement and discussions.
In enterprises, domain and technical knowledge are often spread among different people. A discussion among all these people often leads to good questions, options, and product ideas.
If requirements are just written down and handed over, this discussion does not happen. Similarly, if developers and testers estimate them separately, this discussion doesn’t happen.
Without conversations, a user story can never be considered a user-story. Period.
Planning Poker and Conversation
Planning poker helps team-members in having a conversation on the requirement without getting influenced by peers. That’s the reason, each estimator privately selects a Planning Poker card representing his or her agile estimation.
In case, estimates vary, people explain their reasons. With this conversation, people understand the requirement a bit more and come on the same page.
Developers, testers, business analysts or UX designers have varied perspectives. If they estimate in isolation, they’ll never get to know the perspective of others. That way, they might lose the opportunity to understand the requirement in totality.
So as you play planning poker, the goal is not to come up with perfect estimation.
The idea is to understand the requirement in totality.
Story point as a number is just a side-effect of planning poker exercise.