Przejdź do głównej zawartości

Start with something irrational

In this post I want to provide some examples how a Scrum Master can use irrational cases to foster discussion at Sprint Planning.

By irrational case I mean here asking the team for an opinion about an irrational amount of work or considering an irrational amount of time to complete some work. Here are the examples:

A Scrum Team is planning to execute some manual regression tests that they know cannot be completed in one sprint. They want to spread the execution through a few next sprints. The Product Owner wants to get agreement with the Development Team on how much of the regression can be completed in the current sprint. The regression has already been divided into well defined, small or medium backlog items.

The Development Team stucks in the discussion and they find it difficult to discuss how much of the regression they can do. The Scrum Master may ask questions like these:
  • (A) can you do exactly one regression backlog item in this sprint?
  • (B) can you do half of the regression in this sprint?
Question A has much more power than it seems. One item of regression is already something. It is definitely better than zero regression items. The Development Team is very likely to say "yes, we can". If they can do one, maybe they can do two. Continue asking...

Question B is targeted at establishing a limit: is there an amount of regression that we think is maximum we can take into this sprint. Even at the expense of not doing any functional stories, or very little functional stories. In order to establish this maximum amount, we can start from an amount that we know is not realistic, like half of regression.

Another example is the ability of a Development Team to work concurrently on a story. Sometimes it is a challenge for a team to have multiple developers working on a single story. The Scrum Master wants to guide the Development Team to establish how many developers can possibly work on that story to help them understand the possible shortest duration of work. So, similarly, the questions could be:
  • can this story be worked on by one developer? Certainly yes, but if so, can we have two? Or three?
  • can this story be worked on by 9 developers? It is not likely that this happens in real life, so they are likely to say "no". But then maybe 6 or 7 is good?
My last example here is about longer term planning. There is an epic that may take several months to develop. Everybody knows it is going to take some time, but nobody is willing to stand up and say "that's going to be three months". Again, we are after establishing boundaries:
  • can this epic be developed in, say two sprints? we know the team will say "no", but let's continue the discussion - maybe four sprints is enough?
  • assuming this epic is really tough and most of things that may go wrong actually go wrong - can this work extend beyond 9 months? No... that's unprecedented. Not even with the hardest and biggest epics we remember did it happen. OK, so then we know at least that it is going to take less than that. How about 6 months?
The examples given above may seem a bit naive and we can expect criticism along the lines "what use do we have from establishing boundary values that are so apart from each other?". Don't be discouraged by that. Even if, judging by numbers, the boundary values are not extremely useful, they are still great starting points for fostering discussion and clearly presenting some tangible points the Development Team can consider.


Popularne posty z tego bloga

Unit Testing code with IO file operations (in Python)

We may often come across a piece of code that was written without Unit Tests at all. In addition, the piece of code may be dealing with IO like file writing and reading, which makes it more difficult to Unit Test it when we are trying to refactor and modify. Let's suppose the code in question looks like this:

def writeInitialsToFile(filename, name, surname):
    initials = name[0] + '.' + surname[0] + '.'
    with open(filename, 'w') as file:

def readInitials(filename):
    initials = None
    with open(filename, 'r') as file:
        initials = file.readline()
    return initials

A straightforward and bad idea would be to write a couple of Unit Tests that make use of a real file and simply test the reading and writing. Is therea a better way to test this code?

First of all, we need a way to replace the real file with something else. For both reading and writing we will now have a couple of functions, one that expects a stream fo…

Piotr's Less Obvious Advice on Google Mock: State maintenance

Google Mock provides several ways to maintain state inside mock objects. One way of implementing state maintenance is with SaveArg. Consider the following example.

We have a class Configurator, which allows a caller to set and get values of a parameter:

class Configurator

    virtual ~Configurator() {}

    virtual void setParamX(int n) = 0;
    virtual int getParamX() = 0;

And we have a class Client that calls Configurator's methods and it also has a method incParamXBy, that can be used to increase the current value of paramX by a certain value.

class Client

    Client(Configurator & cfg);
    virtual ~Client() {}

    void setParamX(int n);
    void incParamXBy(int n);
    int getParamX();


    Configurator & _cfg;

incParamXBy internally calls setParamX and getParamX on Configurator:

void Client::incParamXBy(int n)
    _cfg.setParamX(_cfg.getParamX() + n);

Let's assume that the initial value of paramX is A and that we want to increase paramX by…

Piotr's Less Obvious Advice on Google Mock: Returning new objects from a mock

Google Mock provides a way to return newly created objects from a mock method. Suppose we have a  Generator class that is supposed to generate new objects when createNewRecord method is called:

class Generator
    virtual ~Generator() {}
    virtual Record * createNewRecord() = 0;

...and suppose we want to mock this class:

class MockGenerator : public Generator
    MOCK_METHOD0(createNewRecord, Record * ());

Suppose the caller class Client has run method defined as follows:

void Client::run()
    for(int i = 0; i < 3; i++)
        rec_tab[i] = gen.createNewRecord();

We want the mock to return a pointer to a new object each time createNewRecord is called. This is how we can express this in the test code:

TEST(ClientTest, CanRun)
    MockGenerator gen;
    Client c(gen);

    EXPECT_CALL(gen, createNewRecord())
                 //this is equivalent of returning new Record(1,2,3)