The five dysfunctions of a team – How to build a great team
 

I got an opportunity to drive ‘team book reading’ with my highly competent team for one of the very critical facets of team building i.e. “What it takes to be successful as a Team”. The book chose was “The five dysfunctions of a team – A leadership fable” which I personally found very interesting hence thought of sharing the summary with you all.

Precisely the book talks about the five dysfunctions of a team that restricts the team to be successful. It is very important to understand and overcome them in order to be more effective as a team. The dysfunctions are

Absence of trust
Trust & respect are the foundation stones of any relationship be it a home or office. If the members of the team do not trust each other then they cannot be completely honest with each other.

Hence “Create Trust” by following but not limited to:

  • 360-degree feedback
  • Spend time together
  • Understand each other personal history
  • Believe in each other
  • Be honest

Fear of conflict – Without trust, team members will not have healthy debates that are necessary to arrive at better thought through decisions.
It’s very important to have open lines of communication (so that everyone is clear & aligned). Always remember

  • Open discussions. Debate leads to a better solution
  • Focus on the issue, not the individual.

Hence “Value Conflict” (It has to be in a healthy way!) by following but not limited to:

  • Straight talk
  • Calling people on behavior traits that demonstrate fear of conflict
  • Identify how we respond
  • The leader leads in behavior

Lack of commitment – If the team has not aligned to a decision then the individual members who did not agree with the final decision will ultimately be less committed to that decision. It is important to know that the “Alignment” is more important than agreement

Hence “Encourage commitment” by following but not limited to:

  • Summaries decisions made in group discussions or meetings
  • Come to consensus — Any decision is better than no decision – Timeboxing decisions.
  • Clarify all scenarios including worst-case ones.
  • Talk it loud, hear everyone’s opinion.

Avoidance of accountability – If they are not committed to the course of action, then they are less likely to feel accountable (or hold other people accountable). Lack of clarity of roles & responsibilities and not holding individuals accountable leads to “Avoidance of accountability”
Hence “Promote Accountability” by following but not limited to

  • Open disclosure of goals, standards, and metrics
  • Continuous progress reviews
  • Reward for a team not individual

Inattention to results – If the individuals are not accountable, they are less likely to care about the group results (Instead they would focus on achieving their individual goals).
Hence “Celebrate Results” by following but not limited to:

  • Group declaration of results
  • The reviews to be based on results.
  • The leader should lead to behavior.

Disclaimer “This is a just summary of the book we read – In order to have more details, you are required to read the complete book”.

You can find the book at this link

or

Click on below

100 Best Agile Blogging Websites – 2019 List
 

Top 100 Agile Blogs websites

Below is the top 100 Agile websites list published by AgileChamps team. The process followed to identify top 100 sites is:-

  1. Identified few core keywords used for Agile.
  2. These keywords are used against the majority of top search engines.
  3. The websites coming on first few pages are identified.  Approx. 1200 plus websites are shortlisted.
  4. Identified Alexa Rank for all of them.
  5. All the websites under 15 million ranks are reviewed individually.
  6. The websites which are heavy centric on Agile are marked and rest are removed.
  7. At this point, top 200 websites are shortlisted for final review and research. The top 100 are picked after spending a good time with each and every website.

The list may not be 100% perfect but it should be close as there are chances that some of the good websites on Agile are missed. If you think, you have an Agile Blogging site which is not listed here, please do mention in the comment section with Alexa rank and we would include that in below list.

Rank Agile Blogging Site Alexa Rank Comments
1 http://softwaredevelopmenttoday.com/ 1030 Improving the world with software
2 http://agilescout.wpengine.com/ 3078 Agile Software Development News
3 http://agile.dzone.com/ 4167 Agile and Technology
4 http://www.infoworld.com/ 11991
5 http://blogs.msdn.com/b/jmeier/ 12181
6 http://martinfowler.com/ 29470
7 http://scrumalliance.org/ 36377
8 http://geekswithblogs.net/Default.aspx 36908 Agile and Technology
9 http://blog.scrum.org 62603
10 http://www.mountaingoatsoftware.com/ 65325
11 http://www.versionone.com 106619
12 http://www.lean.org/ 143610
13 http://blog.xebia.com 157824
14 http://www.romanpichler.com/ 180494
15 http://www.allaboutagile.com/ 181443
16 http://agilewarrior.wordpress.com/ 257143
17 http://scrummethodology.com/ 269615
18 http://blog.crisp.se/henrikkniberg 279696
19 http://www.torbenrick.eu/blog/ 286285
20 http://www.scruminc.com/ 327659
21 http://www.shmula.com/ 345374
22 http://www.solutionsiq.com/ 359293
23 http://tynerblain.com/blog/ 392184
24 http://www.leadingagile.com/ 396993
25 http://management.curiouscatblog.net/ 420641
26 http://www.agileforall.com/ 451259
27 http://www.marcusoft.net/ 473266
28 http://alistair.cockburn.us/Agile+development 505811
29 http://www.agile42.com 529073
30 http://services.leankanban.com 540509
31 http://www.agileweboperations.com/ 563971
32 http://agilescout.com/ 574286
33 https://age-of-product.com 600556
34 http://www.jrothman.com/blogs/ 608049 Management and Agile
35 http://blog.retrium.com 681480
36 http://tastycupcakes.org/ 736304
37 http://www.netobjectives.com 767821
38 http://jamesshore.com/ 768661
39 http://ronjeffries.com/ 791006
40 http://www.klocwork.com 799097
41 http://www.personalkanban.com/ 806918
42 http://www.agileadvice.com/ 881368
43 http://benlinders.com 908226
44 http://www.scrumexpert.com/ 941122
45 http://brodzinski.com/ 950714
46 http://blogs.agilefaqs.com 979367
47 http://herdingcats.typepad.com 995606
48 http://scrumology.com/ 1105693
49 http://agilepainrelief.com/ 1210659
50 http://blog.3back.com/ 1300016
51 http://leadinganswers.typepad.com 1309169
52 http://www.implementingscrum.com/ 1340427
53 http://kenschwaber.wordpress.com/ 1454803
54 http://testobsessed.com/ 1567560
55 http://www.agilitrix.com/ 1590376
56 http://lithespeed.com/ 1674920
57 http://lisacrispin.com/ 1705271
58 http://guntherverheyen.com 1879037
59 http://www.betterprojects.net/ 1917210
60 http://agilesoftwaredevelopment.com/ 1917606
61 http://www.agile-ux.com/ 1948198
62 http://leansoftwareengineering.com/ 2054154
63 http://agilecoach.typepad.com 2064719
64 http://www.agilistapm.com/ 2302141
65 http://borisgloger.com/ 2332692
66 http://www.estherderby.com/ 2377232
67 http://www.makinggoodsoftware.com/ 2522442
68 http://www.growingagile.co.za 2552857
69 http://www.ontheagilepath.net 2578280
70 http://www.cindyalvarez.com/ 2585993
71 http://www.jbrains.ca 2606431
72 http://www.scrum-breakfast.com/ 2632324
73 http://www.dkrimmer.de 2667951
74 http://leanandkanban.wordpress.com/ 2726139
75 http://blog.agilegamedevelopment.com/ 2726568
76 http://www.gettingagile.com/ 2729011
77 http://brainslink.com/ 2808821
78 http://blog.oikosofy.com 2893584
79 http://availagility.co.uk/ 3117999
80 http://www.leanessays.com/ 3134021
81 http://kellycrew.wordpress.com/ 3194994
82 http://scrumcoaching.wordpress.com/ 3397983
83 https://www.agilechamps.com 3420233 Based on real time experiences. Agile becomes simple.
84 http://www.coachingagileteams.com/ 3493804
85 http://www.derekhuether.com 3499622
86 http://www.axisagile.com.au 3630517
87 http://www.softwareresults.us/ 3658561
88 http://indigoblue.co.uk 3671917
89 http://www.agiletrainings.eu 3740017
90 http://hanoulle.be/ 3782502
91 http://lmsgoncalves.com 4120325
92 http://fragile.org.uk/ 4235666
93 http://theagileexecutive.com/ 4479652
94 http://scalingsoftwareagility.wordpress.com/ 4543469
95 https://scrumfamily.wordpress.com/ 4603896
96 http://www.tinypm.com/blog/ 4815953
97 http://catenary.wordpress.com/ 5292497
98 http://www.agilecoach.ca/ 5352264
99 http://www.thoughtclusters.com/ 5547969
100 http://agilemindstorm.com/ 6605622

I would really appreciate if you can provide a link to this blog to your website if your website is listed above.

BDD (Behavior Driven Development)
 

In the previous article we looked at how to do Test Driven Development (TDD) while doing the XP (Extreme Programming). In XP, the implementation of the tasks are done in the steering phase of the iteration planning. One of the tenets of the steering phase is “functional tests are run”. In this article we will see how to create functional tests using Behavior driven development (BDD) and its benefits.

Following are the some of the benefits of automated functional tests.

  • Functionality experienced by the User is tested
  • Saves testing time for the developers
  • Test in every environment (Dev, QA, Stage) without much effort
  • Generates confidence in every stake holder

Tools required for doing BDD in .Net

There are various tools available to do BDD in .Net. I have listed few of them below

SpecFlow is one of the most popular tools used in the .Net/C# community. And in this blog lets use the same. The tool comes as a Visual Studio Extension and can be downloaded directly from VS.

Creating a SpecFlow Project

Once SpecFlow extension is installed, the template required for doing BDD will be installed.

  • Create a simple “Class Library” Project in Visual studio
  • In the project, create a SpecFlow Feature file

Selecting the test framework

Before we Create/execute the scenario, we need to wire the SpecFlow with a compatible test framework. To do that we need to make changes to the app.Config file of the project.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <configSections>
    <section name="specFlow" type="TechTalk.SpecFlow.Configuration.ConfigurationSectionHandler, TechTalk.SpecFlow" />
  </configSections>
  <specFlow>
    <!-- For additional details on SpecFlow configuration options see http://go.specflow.org/doc-config -->
  <!-- For additional details on SpecFlow configuration options see http://go.specflow.org/doc-config -->
    <unitTestProvider name="xUnit" />
  </specFlow>
</configuration>

In this example we are using XUnit as the testing framework. SpecFlow supports a series of testing frameworks and more details can be found here.

Creating the Behavior

Now, let us look at how to create a functional test using behavior driven approach. Let’s consider the following story while creating a POS (point of sale) application for a super market.

“As a Supermarket POS app developer,  i would like the API to Give the total amount while billing so that I can wire up API against the UI.

Let’s write the Behavior required in order to implement the above API requirement .

Feature: SuperMarketProductsAPI
	As a Supermarket Biller 
	i would like the API to
	Give the total amount while billing
@SmokeTest
Scenario: Find the total amount while billing
	Given Shopping cart is filled with all the items required by consumer
	And Campaign information for the month is available in the system
	When I pass the cart to create bill API
	Then the total bill amount should be calculated

The above specification is written using the custom language (testing DSL) create by the specflow.org. (Please read about what is DSL here.)

There are 2 parts to the above Specflow specification

  • Feature – Denotes bigger context (description/story) of the application
  • Scenario – Specific workflow or behavior of the system under the feature. Each scenario has the following sub-parts
    • Given, And – describes what we already assumed available
    • When – The specific action which will trigger the workflow/behavior
    • Then  – expected behavior

 

Creating step definitions

When we run the unit test corresponding to the above test we it will fail as there are no definitions corresponding to the above scenarios.

Now Right Click on the feature file and select “Generate step Definitions”

You will see the pop-up like below, select “Generate” and then “Save” the file.

The file will have the details about “what SpecFlow should do when test is executed”.

using System;
using TechTalk.SpecFlow;

namespace SuperMarketFunctionalTests
{
    [Binding]
    public class SuperMarketProductsAPISteps
    {
        [Given(@"Shopping cart is filled with all the items required by consumer")]
        public void GivenShoppingCartIsFilledWithAllTheItemsRequiredByConsumer()
        {
            ScenarioContext.Current.Pending();
        }
        
        [Given(@"Campaign information for the month is available in the system")]
        public void GivenCampaignInformationForTheMonthIsAvailableInTheSystem()
        {
            ScenarioContext.Current.Pending();
        }
        
        [When(@"I pass the cart to create bill API")]
        public void WhenIPassTheCartToCreateBillAPI()
        {
            ScenarioContext.Current.Pending();
        }
        
        [Then(@"the total bill amount should be calculated")]
        public void ThenTheTotalBillAmountShouldBeCalculated()
        {
            ScenarioContext.Current.Pending();
        }
    }
}

When you build the project and execute the test corresponding to this, it will fail. This is because none of the parts of the test (given, when, then) are having implementation.

Writing code to make it work

Now that the behavior has been created, we are good to validate that with the team and implement the code/functionality corresponding to the requirement. Of course using best coding practices like TDD 🙂

Making the behavior test pass

In order to make the behavior test pass we need to write the implementation in the “Step Definition” file.

namespace SuperMarketFunctionalTests
{
    using Newtonsoft.Json;
    using System.Collections.Generic;
    using System.Net.Http;
    using TechTalk.SpecFlow;
    using Xunit;

    [Binding]
    public class SuperMarketProductsAPISteps
    {
        Product P1 = new Product { Name = "test1", Cost = 5 };
        Product P2 = new Product { Name = "test2", Cost = 10 };
        ShoppingCart cart;
        List<Campaign> campaign;
        Bill bill;
        [Given(@"Shopping cart is filled with all the items required by consumer")]
        public void GivenShoppingCartIsFilledWithAllTheItemsRequiredByConsumer()
        {
            cart = new ShoppingCart { Products = new List<Product> { P1, P2 } };
        }
        
        [Given(@"Campaign information for the month is available in the system")]
        public void GivenCampaignInformationForTheMonthIsAvailableInTheSystem()
        {
            campaign = new List<Campaign> { new Campaign { product = P1, discount = 1 } };
        }
        
        [When(@"I pass the cart to create bill API")]
        public void WhenIPassTheCartToCreateBillAPI()
        {
            var client = new HttpClient();
            var response = client.PostAsync("http://myapi.supermarket.com", new StringContent(JsonConvert.SerializeObject(cart))).Result;
            var output = response.Content.ReadAsStringAsync().Result;
            bill = JsonConvert.DeserializeObject<Bill>(output);
        }
        
        [Then(@"the total bill amount should be calculated")]
        public void ThenTheTotalBillAmountShouldBeCalculated()
        {
            Assert.True(bill.totalAmount == 14);
        }
    }
}

Once the code is there we can see the behavior test pass.

Conclusion

BDD is very powerful way of ensuring high code quality in conjunction with business requirement. In Extreme programming (XP) , BDD is considered to be a very important practice where functional tests are mandated to run at least once during the iteration.  Is BDD/Functional tests helping your team/business in achieving success or not ? Do let us know your thoughts.

Kanban – step by step implementation
 

You are ready to leverage Kanban in your project.  At this moment you are convinced that Kanban works, it could be a good tool for your project and you understand when this is to be used. The big question is how to go about it.  Let’s discuss that in simplest possible manner.

Visualize your work and existing resources – You need to understand answers to following questions.  What kind of work or EPICs do you have? How long it to complete them?  How many team members you have? What are their capabilities? Customer priority? Release cycle?  What is the existing set of processes used at your BU or org level? How do you get work and what is the priority? The delivery expectations?

Setup Kanban Board – Once you have an answer to #1, you can set a Kanban board. For that, you need various stages, criteria (Definition of complete for that stage in order to be ready to move the item to next stage). You can have a white board and sticky notes to build your kanban board. You can leverage tools like Trello instead of leverage whiteboard/sticky notes.  This may change over a period of time hence starting with Todo, In Progress and Done stages can be a good idea.

Define WIP limit – The WIP limit is assigned to each stage (Represents individual column). The WIP limit restricts team to add more items in the specific stage. This literally removes lots of waste. It does not allow you to focus only on one stage instead encourages continuous production.

Identify and Define Roles and Responsibilities – Kanban doesn’t prescribe specific roles but it is a good idea to have a product owner, scrum master and team member roles. Although in typically Kanban projects, the role of SM is very limited.

Start working – Start working on the model. Don’t be rigid on the number of stages, WIP limit, roles, and processes. This gets better over a time. Do not break the WIP limit rule. If you think the limit you set is not right, change it. This is most adaptive process hence most learning will be on the ground. The processes can be adjusted as you move forward.

Matrices/reports – You can have utilization, productivity, cycle time and other matrices. Do watch it closely as this would help you to stabilize the process per company need.  The cumulative workflow diagram would be a really good choice to constantly monitor as it gives you very clear picture in terms of where the project stands.

 

Kanban – Let’s get started
 

Kanban (refers to visual board or billboard in Japanese) is a lean scheduling tool that works on JIT (Just in Time) manufacturing concept. The JIT is a model in which products are built to meet pressing requirements over building it in excess.  This helps to improve productivity, reduce waste by limiting work in progress items, support continuous delivery and maximizing customer value.

Kanban board is a visualization tool as shown above.   The number of stages could of any number depends on your need. For instance, in my previous project, we were using

  • To Do – When the item is groomed and ready to be picked
  • In Progress – The item is picked and being worked on.
  • QA – The development is completed. It is ready for integration testing.
  • Done – Delivered to the customer.

The stages and conditions as I described earlier are subject to individual need. The Kanban process is highly Adaptive.  It does not prescribe any roles. Let’s look at some of the processes or tools in specific order (rigid to adaptive)

Waterfall – More rigid
XP
Scrum
Kanban – More Adaptive

The work in progress plays a critical role. This ensures there is nothing at any stage over produced which result in reducing wastage. There is not a secret formula to set a WIP limit. All you have to look at is how many members you have in time and how many items they can work for you to have expected utilization. When you start, it is perfectly alright to have wrong WIP limit. You can always change it as you move on.

Just to make it more clear, this is how I set up WIP limits for my previous project example where my team size was 11. All of them used to play the role of Developer as well as QA.

To Do – 5  – Wanted to restrict to a number of groom items as we had customer dependency to unblock individual item (Access and other dependencies). Once we get the access to customer environment, we cannot wait for a long time to get started on that.

In Progress – 6 – I always wanted individuals to focus on QA as well as unblocking backlog item to continue the flow hence I limit this to 6.

QA – 2 – Sound interesting. Isn’t it? Well, anything which is dev-done (typically takes 3-4 weeks of development), the QA work was limited to 2 days. Anything which reaches to QA, should be quickly completed and delivered to the customer so that I can recognize my revenue. The advance of two is, an individual must complete it in order to move dev complete items to QA. If the WIP limit is full, even an item is dev complete, it used to remain there.

In addition to above, I kept WIP limited to leverage pair programming benefit as well. I wanted on complicated items folks to pair program. The above number, I reached over a period of time. The initial WIP limit turned our to be wrong which was expected.

The Agile Methods explain some of the core frameworks or agile process tools similarities and differences.

Please refer the following blog for step by step process to implement Kanban in your project.

Kanban – Step by step implementation

Planning & grooming process for distributed (not co-located) agile teams
 

Most agile frameworks encourage team co-location to have

  • Better communication, mutual trust & respect
  • Better alignment and support
  • Lesser operational costs and smooth management resulting in a better outcome.

All of these are designed for achieving better results as a team. Unfortunately with globalization (offshore/onshore model), there are very few teams that are fully co-located.

In such a scenario, sprint ceremonies are often challenging when you are following Scrum or XP model. In this article, I am going to focus only on planning and grooming ceremonies. I have tried this approach in many teams in the past with significant success.

Planning and Grooming
Agilechamps – Planning and grooming

Assumption

In order to better understand the model, let’s assume that you have one sprint team with 12 members split equally into two teams and separated by multiple time zones. The product owner and Scrum master are co-located and duration of each sprint is 2 weeks long, starting on Tuesday. Assume the team velocity is 40 story points, completing approximately 10 features and 10 bugs in a given sprint on an average.  For this example, let us assume the teams to be located in India and the USA J

Approach

The product owner tries to ensure that at least 2 sprints worth of work is well prioritized at any given time. The team focuses on getting sprint work done during the first week of sprint. The team assumes 10 hours’ time for each USA and India team in each sprint to pre-groom stories. The teams spend some time each day pre-grooming stories and creating tasks during the second week of the sprint along with the continued effort towards their existing sprint goals. The goal of this exercise is to ensure that both teams have enough clarity on stories to be able to start working on them from day one of the upcoming sprint.

During this period (the second week), individual teams should communicate with the product owner or other members of the team to retrieve as much information as possible to flesh out requirements and discover potential blockers.

While this may appear a little tough in the beginning, it gets better over time as team members gradually become accustomed to the code base and business functionality, and are able to make better-educated guesses and assumptions about the stories. Initially, teams might even find themselves spending close to 10 hours a week in these activities, but the time needed drops off significantly in due course. This is especially true for teams that are less exposed to business or may be newly formed.

At this point, both teams have a better understanding of stories what they have groomed. During the planning meeting, both teams talk about each story they have groomed. I would personally suggest teams conduct sprint planning meetings on the last day of the sprint. This ensures that the first day of the next sprint is not wasted deciding what to work on.

Pointing stories is a group activity where inputs from all stakeholders can be considered while assigning points to stories.

Both the team collectively go with sprint commitments after the planning meeting.

Benefits

  • Combined planning meetings are short as at least one of the team has clarity over requirements for each story. I have often seen individuals get on to planning meeting with little or no knowledge about stories resulting in long meetings. This also results in only one team being engaged in the meeting while the others become impatient and disengaged.
  • Product owners are human. It is normal for them to not have all the answers up front. This approach gives them sufficient time to gather missing details; details that they might not even have considered necessary unless brought up by developers
  • The team gets enough time to groom stories since they often have questions for the business owners or for other teams that are easy to answer, but a response needs a turnaround time of a day or two because of time zone differences.
  • The team who has less context on business come up to speed with business, processes, and resolving dependencies wherever applicable.
  • A geographically split team doesn’t mean individuals have to work in isolation.

This model helps teams realize a number of benefits which include (but are not limited to):

  • Improved quality
  • Better commitment
  • High productivity
  • High morale
  • Better team bonding
Agile Capacity Planning (Download Template for free)
 

What is a Capacity Planning

The number of productive hours available for a sprint is called sprint capacity. The capacity is calculated before starting a sprint to identify how many stories team can accomplish for the upcoming sprint. This process is called capacity planning. This helps the team to make a commitment (How many story-points team would complete).

How to do Capacity Planning

You can download the template for capacity planning available at

Download AC Capacity Planning Template

Follow below steps

  1. Provide sprint start and end date. State daily total hours available each day for one person.
  2. Mention all the team member names (Column B11 onwards)
  3. Set high-level default percentages and click “Set Default Allocation” Button.
  4. The defaults will be set. These can be updated for individuals as per your team allocation.
  5.  Click “Plan Button”
  6. This would open capacity sheet with available hours for each individual for all days (Start to end of the sprint)
  7. You can make changes to individuals availability on specific days. Consider holidays, time off and other factors which affect hours for given days.
  8. Fill in details of past sprints if you have data. If not, you would start having that from next sprint onwards once you start using this planner.
  9. Based on past sprint data you get hours per story points in the Capacity sheet that would help us to derive how many story points we can really commit for upcoming sprint for which we are doing capacity planning.

Please note you can use the template I provided or any other template you or your company already have. My goal is just to make the process easy and make you understand the benefit.

Benefits

  • The availability percentage help us to identify available hours which eventually help us to pick the right amount of work for a given sprint.
  • Many sprint team does this manually which has two disadvantages
    • The chances of making mistake are high.
    • The velocity is either considered by averaging past few sprints or simply picking velocity of the previous sprint.  The better way is to multiply your capacity of a team with focus factor.

Focus Factor    =    (Average Velocity of previous sprints)/(Average  Capacity of previous sprints)

  • Improves focus and commitment which in turn increases chances of sprint success.
  • The holistic view of data that you get for past sprints using capacity planning does help in taking decisions and continuous improvement.

In order to see the real benefit of this template, you are expected to use the template for at least 3-4 sprints. Further, as you move, you see more benefits.

There are multiple teams I know leveraging this template I shared and I see them getting befitted out of it. This is the most basic template while if you think you want to add more to it, just provide the details in terms of what do you want and I will incorporate it into my template.

Question 1. How do I establish my capacity without historical data?

  1. Start with 8 story points (6 if the team is not very experienced) for each FTE. Let’s say there are 5 Developers and Testers (It would be 6*8 = 48). Do ensure to avoid adding points for Scrum Master or product owner.
  2. Subtract approx vacations from today (48 – Total vacation days)
  3. Find a story which would take less than a day and assign that to 1 story points
  4. You can estimate every other story relative to that. Do leverage Fibonacci series (1,2,3,5,8,13,20,40,80….) – Slight change for better results
  5. Don’t overdo it. Always remember that you start with something and get better.  A small effort is good enough. Lots of effort on estimation would not yield any results

Question 2. My team average velocity is 40 but now the whole team is moved to a newer sprint product team. Can I go with the same number? 

As I said, you can go with approx, to begin with, while if the product is completely new, reduce the number or better to use the same technique assuming there is no historical data.

 

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.