Estimation – Planning Poker
 

What is a planning poker (& Facts)

  • Planning poker is a consensus-based technique to estimate the effort in an Agile project. It is sometimes referred as scrum poker as well.
  • Performed using a deck of cards (referred as planning poker cards). The Fibonacci sequence (i.e. 1, 2, 3, 5, 8, 13, 21, 34…) are printed on cards (most popular and widely used). One can use any other sequence which suits your need. For instance, doubling card numbers (1/2, 1, 2, 4, 8, 16, 32…) is quite popular as well. These numbers represent story points.
  • You can leverage software tools(tons of tools available online) over cards to make the process easy and compiling estimation for each story.
  • The teams come to approx estimate and keep getting better with time.
  • It’s a collaborative effort and team activity. The entire team is expected to participate in this activity. If your scrum master is going contribute technically then he/she should participate along with programmer, testers, DBA etc. If the scrum master is not going to contribute technically while he/she has a solid technical background then it is advisable to include him.
  • The PO may be included too if he/she has strong technical background.
  • It is derived from WBD (Wide Band Delphi), Analogous and WBS (Work Breakdown Structure) estimation methodologies.
  • The stories should be broken down enough so that estimation will not go beyond. One general rule is to break down the tasks further if it is scored 13 or above.  There are instances where you cannot really do that while in most cases it’s not very tough to do so.
  • The voting option can always be used when there is a conflict in estimate post discussion.
  • If the estimation is done using story points then its easy to sum them up to match velocity so that sprint commitment can be made.  The hours is not advisable as by definition user stories are a high-level description of functionalities hence chances are slim to get close to accurate hours when estimating.

Implementation

  • One of the team members is selected as moderator (Typically product owner or scrum master)
  • Every individual is given deck of cards with numbers printed on it. If the software product is used over cards, a session is created and everyone logs into that to select their number for every story.
  • The moderator reads out the story loud with all the details. The whole team discusses to ensure everyone has a fair understanding and missing items are covered.
  • During this discussions, any question which comes with respect to functional details, PO answers that.  Remember, it’s a collective effort hence anybody who has more context can clarify the doubt though a final decision is taken by PO when it comes to functionality.
  • Every individual secretly selects his/her card representing their estimate which is later shown to the rest of the team once everyone is done with their estimate for a given story.
  • If the entire team come to the same estimate, it becomes an estimate for a given story.
  • Team members which have higher or lower estimate compare to rest of the team would explain their viewpoints.  The team can take some time to discuss that further. If needed, this process is repeated for the same story or the whole team agrees on one final number.
  • This estimation process is repeated for every story.
  • It is perfectly alright to have a varying estimation as the team gets mature over a time and moreover, understanding of business and technology will keep getting it better.

Benefits

  • Better understanding of requirements because
    • The entire team is involved in estimation and
    • Discussions around each story specifically unknown areas.
  • It’s easy and a fun way to estimate.
  • The estimates are not dumped instead its collective team estimate. This leads to high morale, a greater sense of ownership, team responsibility and commitment.
  • Everyone has a say on the estimation. The equal voice whether an individual with zero or 10+ years of experience creates trust and positive environment.
Should I start thinking about switching from Scrum to Kanban?
 

A group of project managers gathered to discuss the challenges they have with the existing process with senior management.  Let’s look at some of the interesting areas what they have put forwarded on the table (I am sure you can relate one or more areas if you have managed agile teams)

 

Project Manager 1: (Team is afraid of Sprint failure) My team have very fewer items in sprint compare to what they can accomplish as they are scared of sprint failure.  Despite that, I don’t have successful sprints as one or items roll most times as we get blocked. I can’t allow my team to pick more middle of a sprint.

Project Manager 2: (Prod issues; Lot of support to other teams) My team builds new feature while I am expected to support some of the other teams for whom we provide back-end services. The requests coming from them is our top priority whenever it’s related to prod for them.  The amount of work which comes from different teams vary and we cannot assign fixed bandwidth to deal with those issues. Most of our Sprint we have one of these two situations

  • The sprint fails because we need to focus on supporting other teams.
  • We are done much before the sprint ends.  Pulling new work is not allowed mid-sprint hence we use that time for learning while this is not a great idea all the times.

Project Manager 3: (Support work; Tickets) I have all the support work. The estimation has been a challenge most times. A bug takes a day or a week, all depends as the product I work for is huge and we have most of newer members.  How can I make sure my sprints are successful and at the same time, we as a team don’t under commit?

Project Manager 4:  (Adaptive to more adaptive) My team hates too many ceremonies and processes. They think of having a lightweight process which is more adaptive over prescriptive,  is much better. All of them are experienced/committed and understand their roles and responsibilities.

Project Manager 5: (Time and material; Longer stories; Unpredictable work) We built adapters and I don’t see the benefit of breaking down and doing that in parts. We have a deadline for every adapter and we kept getting blocked. We are fine to wait as we are on “time and material” contract. Getting blocked from customer end doesn’t harm as billing don’t stop.  How do I fit in a work which takes few weeks to a couple of months?

Project Manager 6: (Frequent priority shiftOur priorities changes very frequently.  Many times we literally have to stop what we are working on and start something else. Getting new work done in next sprint doesn’t help as the work we are doing becomes useless even if that’s completed due to change in priority.

Project Manager 7:  (Customer or Sprint successOur company’s top priority is to manage customers and their expectations while we always focus on velocity and sprint success. This becomes challenging as in order to manage customer priorities, we compromise Scrum priorities or vice versa. Both are not good ideas. In the first option, you are disregarding a process resulting in low team morale and unpredictable outcome.  The later is not acceptable anyway 🙂

Project Manager 8: (The product owner struggles) The PO struggles to lock down the requirements for a week. He keeps adding work to sprint throughout the week, changing existing requirements and even providing/updating acceptance criteria during the sprint.

Projects Manager 9: (Team experience or complex work) My team has challenges with breaking the requirements or estimating the work.  The sprint success matters most to me (Why-Sprint-Success-is-Important). I end up being unhappy most times.

Kanban could be one of the solutions for most of the problems listed above. The comparison of Kanban with Scrum/XP and some of the core frameworks is available here

The Sprint success is really important when you talk about Scrum. The Sprint fails due to the variety of reasons like team experience, The challenges with breaking down stories, unpredictable work, Customer focus precedes team priorities, support work and many other challenges as listed above. In many times either we run too much to having successful sprint (By means of slogging or patch up work) or do not think of successful sprint at all. Both are not good options.

In my upcoming blogs, I would be talking in detail about how to use Kanban, best practices, myths and an easy shift from existing process to Kanban. Please provide your comments below. This would help me to cover all aspect in my next set of blogs on Kanban.

5 actionable you can take today to be more agile
 

Be More Agile

Most of the teams in the software world follow Agile process and practices. Following Agile is fundamentally different from being Agile and in this article, we will talk about some of the actions you can take today to be more agile.

do you follow?

  1. Shed Ego:  Ego is a big blocker for our progress irrespective of being in the Agile world or not. But this becomes even more evident and blocks our every step in an Agile environment. There are lots of articles about egoless development.
  2. Be open to collaborate : When we are open and talk our mind, we automatically become more agile. The restrictions and mental blocks to speak our mind openly to the team are the biggest bottlenecks to free flow of information and ideas. Psychologists call it emotional security to speak our mind.
  3. Don’t Use communication tools: In this age of technology, the tools are plenty for communication,  but none of them provide the connect of the face to face communication. (Agile principle)
  4. Focus on the outcome: Lot many times, the agile manifesto is being misinterpreted (“working code is a measure of progress”).  Unfortunately, it does not talk about production. Some teams get very complacent when they get their working code in “QA” or “Stage” environments for example. There is no result when the working code is not in production. At the end of the day outcome matters.
  5. Get things done: Just like any other methodologies, the trap always exists when teams get lost in the process and meetings. The important part of the business and the product is to deliver things. So never move eyes away from the delivery.

These are the few actionable you can take today to be more agile and be awesome developers and technologists. So take action now!

What are common Agile Methodologies?
 

Agile Methods

The Agile is not just following Scrum or XP. There are many other agile frameworks or methodologies available in the Agile world which are leveraged based on type of work or a project. There is none better than other.  The use completely depends on the type of the project you have.  There are many methodologies available in the market while I will be listing down high-level details about some of the core methodologies below.

  • Scrum
    • The team works in iterations (Called sprints) that are typically 2 or 4 weeks.
    • The engineering practices are not prescribed.
    • The scrum does not encourage change within sprint once a commitment is made.
    • The backlog is prioritized while within sprints team decides how to go about picking items. The priority is typically given by product owner.
    • The releases happened after the end of iterations.
    • The scrum can be used for non-software products.
    • Encourages feedback early while it’s fine to reach to the point till you have sprint review.
  • Extreme Programming (XP)
    • The team works in iterations that are typically 1 or 2 weeks.
    • The engineering practices (TDD, BDD, pair programming, automated testing, refactoring etc.) are prescribed.
    • The XP teams are open for changes as long as the feature hasn’t started or they have similar size of an item which can be swapped.
    • The work is done in strictly priority order. The priority is determined by the customer.
    • The focus is more on small and frequent releases.
    • XP focuses on programming.
    • Immediate Feedback loops.
  • Lean and Kanban
    • The lean concept has come from lean manufacturing where the focus was a continuous flow of work and eliminating waste (Muda).
    • Kanban (Billboard or signal board or visual board in Japanese) is one of the lean methodology sometimes referred as Lean Kanban.
    • The core focus is on visualization, work in progress limits, flow, and continuous delivery. The work is in one of the categories (to-do, doing or done). There could be N-number of categories.
    • When we talk about software, it is most suitable for support kind of work.
    • No required time-boxes or iterations.
    • No set process roles are prescribed unlike Scrum where you have three roles defined (Scrum master, product owner, and team member)
  • Feature Driven Development (FDD)
    • An iterative and incremental software development process which is often referred as a lightweight Agile process.
    • The focus is on features.
    • The main purpose of FDD is to deliver tangible, working software repeatedly in a timely fashion.
    • The unit testing, pair programming, refactoring is not important.  Modeling language (like UML) is leveraged and documentation is not mandatory at all.
  • Agile Unified Process (AUP)
    • Simplified version of RUP (Rational Unified Process)
    • The four phases are inception, elaboration, construction and transition.
      • Inception – Stack holder acceptance, Initial requirements, high-level architecture, and scope is baselined here.
      • Elaboration – The detailed design and architecture are accomplished in this phase.
      • Construction – Working software building incrementally.
      • Transition – Release and deployment
    • The focus is on TDD, Refactoring, change management etc.
  • Dynamic Systems Development Method (DSDM)
    • Focus on developing the system dynamically based originally on Rapid Application Development.
    • Incremental prototyping
    • It has primarily 5 phases
      • Feasibility Study
      • Business Study
      • Functional/Business Model Iteration
      • Design and Build Iteration
      • Implementation

Above is very high-level information to get a hang of it. I shall be writing individual blogs about these methodologies in detail in my upcoming blogs.

How can I grow vertically in product based organization?
 

As an Agile team member how can I be an expert at project is one among a common question I hear every time. The world is changing so fast, the evolution of tools and technologies making life so easy when it comes to implementation or writing code. When you talk about career, everyone wants to grow vertically and the easiest option I see to achieve this in product based companies is to get better at product and domain in addition to fulfilling your agile roles and responsibilities. This would help you to stand out in the crowd. To be honest, this is an easy path which lot of others do not want to take.

Vertical Growth

I am listing here top 10 ideas to be considered to grow vertically in product based organization.

  1. Spend 30 minutes to an hour every day to learn about the product by playing with product, testing out functionalities, reviewing code other than your normal work.
  2. Review existing documents around product. Whenever you see an opportunity correct them. Document your learning and contribute your knowledge in organization PAL (Process Asset Library). Writing or teaching anything to people helps you to move the knowledge to your permanent memory.
  3. Whenever you work on any sprint item (like bug, story, tech debt or spike), ensure you understand the user value proposition of that. Always ask yourself why I am doing what I am doing. How does it helps business?
  4. Understand all the integration with your product.
  5. Search on internet to find competitors. Find out what features we are lacking what our competitors have. What is that we have and others don’t have? Propose PO your learning and ideas.
  6. Participate in calls related to vision, roadmap or release planning.
  7. Communicate more with business owners. Understand priorities, business need and what is coming next.
  8. Ask question when in doubt. No question is a stupid question.
  9. Participate in showcases/demos and cross functional calls. Ask questions. Share your knowledge to others in team.
  10. Once in a week have a session with whole team to talk about product, domain, innovations and learning. Encourage everyone to share their thoughts.

I am sure doing some of above would boost your career in product based organization.

How can an Agile Leader be successful?
 

I am listing most important factors which an agile leader must focus on, in order to be successful in his/her role

  • People, people and people

  • Building Relationships with all the stakeholders

  • Business Alignment (Clarity of vision and mission)

  • Self-Organizing Teams

  • Sprint Success and Continuous Improvements

  • Everyone contributes 

  • Relationship within team

  • Collaboration

  • Promote “Fail Faster, succeed sooner”

  • Frequent releases

  • Remove impediments

  • Frequent feedback loops

  • Lots of fun

  • Process alignment

  • Visibility on current status

People

Let me tell you honestly, there is nothing more important than people.  As a leader, you should focus on people, their careers, growth, motivation and anything what you can support them to add value to their personal lives. Don’t forget to appreciate good work and at the same time it is important to provide feedback around areas of improvement.  When you think of growth, think about your team’s growth. When they grow, you grow.

Provide them opportunity to become better individuals. Inspire them to learn and get better. Feel pride in their success.

Building Relationships

Strong relationship with team and stakeholders make life easy. It’s not just about bringing in empowerment while at the same time it is important to understanding everyone’s need and expectations.  The great relationship with business, management and team helps you to have

  • Better insight
  • Access to more information
  • Align people
  • Open culture

Business Alignment and Vision

If you don’t know where you want to go, you will reach nowhere. As an agile leader, you must ensure that there is a clarity of vision and mission for you and your team. Moreover everyone is aligned to business needs and expectations. You should often ask yourself and your team about USP (unique selling proposition) of what you are building.

Self-Organizing Teams and autonomy

Don’t hold your team too tight that they can’t breathe at the same time don’t leave them to do everything by their own assuming they would become so called “self-organizing teams”  by themselves. The ultimate goal should be to build self-organizing team and if you are successful in doing so, the chances of you being successful is very high along with your team.

Sprint Success

Always focus on sprint success. When you start, do it less and then improve. Never get into discussion with business or management that we are delivering enough for our need hence meeting commitment is not important.  Do whatever it takes to make sure your sprint is successful.

Everyone contributes and Continuous Improvements

If this doesn’t happen then slowly you would see your self-organizing team start deteriorating.  Everyone has different skill and competence hence you can have different expectations while everyone has to contribute. One rotten apple spoils entire basket and this no different here.

Relationship within team

If you have happy team that gel well with each other, you are likely to do much more. If you’ve highly competent individuals in team but team members don’t go well with each other over a team which has lessor experience and competence with strong bonding then your chances of getting better output in team with good bonding. Do whatever it takes to make your team align and build a bonding among them. By doing so, you are significantly improving the chances of your success.

Collaboration and Communication

Agile team cannot run in Silo. The collaboration nothing but working with cross functional teams to accomplish a task. This encourages communication among business owners.  The communication within team is also very important. The output will be produced by team and not individuals.  It helps in removing impediments faster as well.

Promote “Fail Faster, succeed sooner”

It’s not a perfect world. In order to be successful with Agile there should be an environment where everyone encourages individuals to experiment. It’s OK to fail and that’s what lead us to be successful.  Fail faster, succeed sooner is something you should not just feel while you are expected to enforce that in your team.

Frequent releases

Release as much as you can. I have seen teams releasing every day or even post every feature completion. This is a challenge at a times or product which are quite big and needs significant testing. More you do, simple it becomes.  The moment you start thinking about releasing frequently, you would focus on automation tests.  That something most times become last priority which is not at all good.

Constant feedback

Don’t wait for showcase to provide feedback. The code review phase is not important to provide the challenges or best practice. Talk more. Provide feedback then and there. Look for ways to get the feedback from customer, PO or other stakeholders as soon as possible.

Lots of fun

Start with fun and then get on to work. Don’t wait for you to be successful to have reward. There is going to be celebration for that as well while create an environment where everyone feels comfortable and enjoy working.

Process alignment

Arrange a training. Talk about process. Doing agile is probably easiest thing while doing it RIGHT is what really needed right mindset. There are many teams I have seen they do “waterfall agile”. They are basically trying to do waterfall within each sprint.  Not good!

Visibility on current status

Create various matrix to ensure things are on track. Utilize standard artifacts like burndown charts, velocity report etc to see where you stand. You can fix the issue and come up with finding a right solution only when you know how are you doing.