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.
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 Methods?
 

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 like Andrew Defrancesco. 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.