Stand up: Why you should talk about your next actionable?

Lots of teams that I work with generally follow the best practices of a Scrum stand up meeting. However, as time goes by team tend to fall into the slippery slope of just reporting what they have accomplished the previous or the current day and completely ignore the next actionable & impediments. This happens more when the team/scrum master is not very strict about the process. In this article, we will see the reasons why this is important and the benefits of the same.

Life without goals

Before we delve deep into practices of Scrum method, we will talk about few general principles how our subconscious works. As per the basic behavioral psychology, there are three parts of the self-concept.

a) Self-Ideal – Goals, aspirations, dreams etc.

b) Self Image – impression about self-based on previous experiences.

c) Self Esteem – Emotional component of how much we like ourselves.

When someone sets goals and achieves them, the self-image corrects and the self-esteem improves. And they start setting bigger goals and continues to go on an upward spiral.

How Psychology relates to Scrum

Whenever a team member talks about “What they will do ” before the next meeting, they are indirectly setting a time-bound goal for themselves. When they come and report the achievement of the same the next day, the self-image and the self-esteem goes up. This will bring more success as the time goes by.

The Sprint is systematically designed methodology using the basic psychology of commit and achieve cycle.

Let’s do an experiment. If you are part of an Agile team, state your goal for the day loudly to your team during the stand-up meeting. You would have that in your back of your mind entire day. At the end the of day, if you accomplish what you stated, you will have an amazing sense of accomplishment.  Otherwise, you feel that you have not done enough. This comes to most members as long as they care about the company and their career. All you have to do is take that seriously and you would find yourself growing much faster than your peers.

I have personally asked this to many people and every time I had the same result. Isn’t it amazing? How simple it is to grow in an Agile team. Isn’t it?

So Next time you are in a stand-up meeting, would you talk about “what you are going to do “?


If you like this article, please share and provide comments.



Top 100 Agile Blogging Websites in the world

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 1030 Improving the world with software
2 3078 Agile Software Development News
3 4167 Agile and Technology
4 11991
5 12181
6 29470
7 36377
8 36908 Agile and Technology
9 62603
10 65325
11 106619
12 143610
13 157824
14 180494
15 181443
16 257143
17 269615
18 279696
19 286285
20 327659
21 345374
22 359293
23 392184
24 396993
25 420641
26 451259
27 473266
28 505811
29 529073
30 540509
31 563971
32 574286
33 600556
34 608049 Management and Agile
35 681480
36 736304
37 767821
38 768661
39 791006
40 799097
41 806918
42 881368
43 908226
44 941122
45 950714
46 979367
47 995606
48 1105693
49 1210659
50 1300016
51 1309169
52 1340427
53 1454803
54 1567560
55 1590376
56 1674920
57 1705271
58 1879037
59 1917210
60 1917606
61 1948198
62 2054154
63 2064719
64 2302141
65 2332692
66 2377232
67 2522442
68 2552857
69 2578280
70 2585993
71 2606431
72 2632324
73 2667951
74 2726139
75 2726568
76 2729011
77 2808821
78 2893584
79 3117999
80 3134021
81 3194994
82 3397983
83 3420233 Based on real time experiences. Agile becomes simple.
84 3493804
85 3499622
86 3630517
87 3658561
88 3671917
89 3740017
90 3782502
91 4120325
92 4235666
93 4479652
94 4543469
95 4603896
96 4815953
97 5292497
98 5352264
99 5547969
100 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"?>
    <section name="specFlow" type="TechTalk.SpecFlow.Configuration.ConfigurationSectionHandler, TechTalk.SpecFlow" />
    <!-- For additional details on SpecFlow configuration options see -->
  <!-- For additional details on SpecFlow configuration options see -->
    <unitTestProvider name="xUnit" />

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
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 (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
    public class SuperMarketProductsAPISteps
        [Given(@"Shopping cart is filled with all the items required by consumer")]
        public void GivenShoppingCartIsFilledWithAllTheItemsRequiredByConsumer()
        [Given(@"Campaign information for the month is available in the system")]
        public void GivenCampaignInformationForTheMonthIsAvailableInTheSystem()
        [When(@"I pass the cart to create bill API")]
        public void WhenIPassTheCartToCreateBillAPI()
        [Then(@"the total bill amount should be calculated")]
        public void ThenTheTotalBillAmountShouldBeCalculated()

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;

    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("", 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.


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.

Perspective Designing

Recently, I was working with a colleague in refactoring one of our projects. As we added tests, we found few code issues and continued refactoring. Was feeling happy as our unit tests were rearing benefits. However, we know TDD or unit testing does not guarantee clean code. As we progressed, the naming conventions consumed a lot of our time. And eventually, it brought us to a discussion about why specific naming conventions can create a better design. Thought I will share our discussions and practices here.

While we design classes for application, we often think of it as a different subject than ourselves (programmer). When I say different subject, we think of it as a different object and not as a person. When a programmer considers classes/interfaces as personalities and thinks from the perspective of the class, design can change drastically. This is what we call “Perspective designing”. Let’s take an Example:

    public interface ITotalTaxCalculator
        decimal Calculate(IEnumerable products);

    public class TotalTaxCalculator : ITotalTaxCalculator
        public decimal Calculate(IEnumerable products)
            decimal total = 0.0;
            //add total of products etc....
            foreach (var product in products)
                using(var dbContext = new ProductContext())
                    var productInDb = dbContext.FistOrDefault(prod => prod.Id == product.Id)
                    total += (total * productInDb.taxRate);
            return total;

In the above example, the name of the class and interface are perfectly fine. But they are impersonal and it’s very hard to think of it as a person and bring in perspective thinking with these names. So we refactored them to ‘ICanCalculateTotalTax’ and  ‘TotalTaxMan’.

public interface ICanCalculateTotalTax
    decimal Calculate(IEnumerable products);

public class TotalTaxMan : ICanCalculatorTotalTax
    public decimal Calculate(IEnumerable products)
        decimal total = 0.0;
        //add total of products etc....
        //blah blah blah..
        total += (total * taxRate);
        return total;

These naming conversions have lots of inspiration from in NServiceBus for their class/Interface names. With the new class and interface names, it’s easy to think of them as personalities. However, this does not guarantee good design. So we needed refactoring. Perspective thinking comes in handy especially while we do refactoring When my colleague and I started putting ourselves in the place of each of the classes. We had very reasonable questions which triggered our object-oriented thinking.

Example1:  As ‘ICanCalculateTotalTax’ , why I am having database related behavior?

Example2: As ‘ICanCalculateTax’, why I am having logic to find which language it needs to be presented?

These questions helped us to refactor the code to follow good design principles. When we implement these interfaces/abstract classes, we have clarity on what the class is capable of doing. So we generalized these naming conventions & questioning attitude and derived below two rules to do Perspective designing (think like a class).

  • Give personality to the names of  classes/interfaces (example: ICanCalculateTax)
  • Use the Agile User Stories way of articulating what the class should and should not do. (example: As ‘ICanCalculateTax’, I should be able to provide behavior to calculate tax)

I think, “Perspective designing” can make classes more object-oriented and best practice like SOLID principles automatically fall in line. Let me know your thoughts.