Scrum Master

Today’s #scrum and #agile thought of the day

By Nicole Forsythe

scrum master


Traditional Marketing Management is On the Verge of Extinction

By Pino Soro

How our marketing team implemented #scrum to become faster and more responsive

Via @ruxit


Pernicious Scrum Anti-Patterns

By Dwight Kingdon

#Scrum anti-patterns in an article at Dr. Dobb’s:…

via Mike Cohn


When SCRUM Stand-Up Meetings feel like an Interrogation

By Thoma Schranz

When #SCRUM Stand-Up Meetings feel like an Interrogation … #agile prodmgmt

Via Paul Brown


That’s all folks!




After a long period away I’m back with more readings.

During this absence  my professional activity moved from Tester to Scrum Master. New experiences, new readings.


And because we are in vacation we have fewer readings.


Rely on Specialists, but Sparingly

by Mike Cohn

Making sandwiches and being specialist. #softwaredevelopment

via Sebastian Malaca


How do you increase velocity?

by  Scrum Alliance

How do you increase velocity? #scrum #agile

via Scrum Alliance

Media preview


How to help a team that is not performing so well

by Luis Gonçalves
How to help a team that is not performing so well – Part II – #scrum #agile #learning #improvement
via Luis Goncalves

Building Better Software

Last week I attended ExpoQA International Conference on Software Testing & Software, in Madrid. There was a lot of very good presentations. Sorry that we can’t attend all of them.

The one that touched me more even wasn’t in the program. But due to a last hour cancelation it was replaced by a presentation by Paul Gerrard about Specification by Example and the Business Story method.

It is amazing when we understand how such a simple thing could resolve such a huge problem like requisite’s flaws.

Some time ago I wrote about these kind of flaws and how we could mitigate them. My theory was close to Business Story method.

The idea of writing Business Stories based on client’s requisites or specifications, describing and giving examples in a clear language, it is simple and powerful. When we send these stories to the client we got the client’s confirmation about the correct understanding about what the he wants.

Whenever I mention Development Team I mean a team of Analysts, Developers, Testers, Technical Writers and User Experience experts.

The truth is that a requisite’s flaw is, most of the times, a communication problem. It happens when the information flows across teams and loose a bit each time it is passed, or a team just didn’t have access to all information.

We all know that a requisite’s flaw is very expensive. This phase is the most expensive where it can happen.

Being a communication issue, why don’t we ever look for experts non IT to help us? An exper in Organizations, a Human Resources specialist, team managers and others, have skills to watch our Development team behavior, find the problems and propose changes.

Why aren’t these people evolved in the Software Development Process definition? Engineers are not the best people to do it, yet we can only fid them in these teams.

What I like most in Business Story method is the fact that it is neither an agile nor a conventional method. We can adapt it to any of them but it still is neither of them.

Another advantage is that the writing of Business Stories is a collaborative process, involving the entire development team.

With this method everyone is automatically informed. The fact that they receive a pack of requisites or specifications, discuss then e rewrite them, consolidates all data among team members. When the client confirms that is really what he wants everyone can start working. Business Analysts write more detailed documentation, programmers write code, testers write test cases while they wait for code to test. All of them have the same information and they are aligned with each other.

It is not necessary to follow a methodology to the letter, instead, we should adapt it to our company and our team, looking to improve our performance.

Construir melhor software


A semana passada estive na ExpoQA International Conference on Software Testing & Software, em Madrid. Assisti a apresentações muito boas. É pena não podermos assistir a todas.

A que mais mexeu comigo, nem sequer estava no programa. Devido a um cancelamento de última hora, foi substituída por uma apresentação do Paul Gerrard , sobre “Especificação com exemplos” (Specification by Example) e o método “Business Story”.

Surpreendente foi perceber como uma coisa tão simples podia resolver um problema tão grave como a falha nos requisitos.

Em tempos escrevi sobre essa falha e como poderia ser mitigada. A minha teoria aproximava-se um pouco do método “Business Story”.

A ideia de escrever “Business Stories” baseadas nos requisitos ou especificações feitas pelo cliente, descrevendo e exemplificando numa linguagem de fácil leitura, é simples e eficaz. Enviando essas “Business Stories” ao cliente, consegue-se uma confirmação da sua parte, do correto entendimento sobre o que pretende.

Sempre que falar em equipa de Desenvolvimento falo de uma equipa constituída por analistas, programadores, testers, especialistas de documentação e user experience.

Na verdade, o problema da falha de requisitos é, na maioria das vezes, um problema de comunicação. Acontece quando a informação é passada sequencialmente pelas equipas, perdendo-se algo pelo caminho, ou quando algumas equipas não recebem a totalidade da informação.

Todos sabemos que uma falha na fase de requisitos é muito cara. É nesta fase do processo de desenvolvimento de software que uma falha tem o custo mais elevado.

Sendo um problema de comunicação, porque é que nunca recorremos a especialistas não IT, para nos ajudar? Um psicólogo especialista em organizações, um gestor de recursos humanos, um gestor de equipas, um gestor de projetos ou outros, têm competências para observar o comportamento das equipas de Desenvolvimento, encontrar falhas e aconselhar alterações.

Porque é que na definição do processo de desenvolvimento de software da nossa empresa, não estão estas pessoas? Os engenheiros não são as melhores pessoas para o fazer, no entanto, só os encontramos a eles nestas equipas.

O que mais gosto no método Business Story é o facto de não ser um método ágil nem convencional. Pode ser adaptado a qualquer um deles, não sendo nenhum dos dois.

Outra vantagem é que a escrita das Business Stories ser um processo colaborativo, envolvendo toda a equipa de Desenvolvimento.

Com este método todas as pessoas ficam naturalmente informadas. O facto de receberem um conjunto de requisitos ou especificações, as discutirem em conjunto e as reescreverem, consolida a informação em todos os elementos da equipa. A confirmação por parte do cliente de que é efetivamente aquilo que pretende, dá o toque de partida para todos iniciarem as suas tarefas no processo de desenvolvimento. Os analistas escrevem os requisitos mais detalhados, os programadores avançam com a programação e os testers escrevem os seus testes, enquanto aguardam pelo código para testar. Todos têm a mesma informação e estão alinhados.

Não é necessário seguir uma metodologia à risca, em vez disso, devemos adapta-la à nossa empresa e à nossa equipa, procurando melhorar o nosso desempenho.



We can’t live without connections and neither our tools can.

Enterprise Tester (ET) allows you to connect to other tools, like Defects and Requirements tools. We need to connect to Enterprise Architect (EA), our requirements tool.
It was a nice surprise to see how simple it is to connect to EA. The connection is done by importing directly from EA’s database without any other components between. Clear and simple. There are other ways but this one is the simplest.
It’s quick and it works well.

A Requirement in EA becomes a Requirement in ET.
A Use Case in EA becomes some Script Tests in ET, a Script for each Scenario.

In EA we organize requirements in a tree of packages. We import requirements to EA by package.
The complete tree is created, under the ET’s requirements package we specify. This way we can keep the same structure we have in EA and this makes easier to read. Depending on the complexity of model in ET we can import the complete model or just one package.

When requirements are modified or new requirements are created in EA we just have to import again the packages to update and add news.

Of course we can create requirements in ET manually. But, as I said, connections are our life!

(previous step Security)


Have a break and think about your team.

Fill in the blanks

by Esther Derby
Fill in the blanks by Esther Derby #communication

via lubaia

What Can You Do About It?

by Catherine Powell

What Can You Do About It? by Catherine Powell #management

via lubaia

I imagined the future that I wanted and I started the construction

By José Baldaia

I imagined the future that I wanted and I started the construction by @jabaldaia

via lubaia

A Competent Tester

By John Stevenson

The expected result was 42. Now what was the test?: A Competent Tester

Via lubaia

When you install Enterprise Tester you’re asked to…

When you install Enterprise Tester you’re asked to create an administrator account. This is the first step into security.
The security system isn’t complex and gets simple to implement.
You have Groups of users and Users. Permissions are define by Group.
Users are independent from projects. instead you assign a User to projects – like in real life.
You can define permissions to all tasks in your team. To people who writes test scripts, the ones that manage iterations, the ones that execute and, very important, the ones that read your test scripts.
Although some of you think that writing test scripts is a waste of time and that you get more results if you spent that time testing, I think test scripts can be useful.
Like everything else in life, there must be a balance between what you write and what you get in return. When I write test scripts, I don’t get in too many details, I don’t describe every little steps. I try to describe what to do and spent more time describing what to check (I wrote check, not test !) to get it useful to others.
I think our test scripts are part of the product documentation. This is why, in Enterprise Tester, we have to create a Group of Users that will not write nor execute tests but will read tests.


Don’t Be Perfect

By Cameron Laird

Nice #dev | Don’t Be Perfect

via Tordf

Tales from the trenches: Essential test case design

by Darren McMillan

Blogged: “Tales from the trenches: Essential test case design” #softwaretesting #qa #testing

Via darren_mcmillan 

Testers!! know your Business (& don’t do that of others!)

By Joel Montvelisky

Posted: Testers!! know your Business (& don’t do that of others!) based on feedback by @jerryweinberg to an old post

Via joelmonte

Agile Brings Changes to Key Roles and Responsibilities

By Dave Moran

Posted: Agile Brings Changes to Key Roles and Responsibilities #Agile #pmiagile

via wvanrheenen

Setting up Enterprise Tester after a break here…

Setting up Enterprise Tester, after a break here I am again.

Enterprise Tester is very easy to install. Once installed you configure it and work with it using web access.

The first step is to create your Organization, and Administrator account and set up your licence. You are ready to go.

An Organization can be your company, your department or your team. You may create more than one.
Our decision is to have one Organization that is our company.

For each organization you add your Enterprise Architect connection and configure your pick lists. Also available are Custom Fields. This is something I like very much, to personalize lists and add new fields.

Custom fields have a reasonable range of types and something better than that – a scope. This means you can have different customization in each of your projects or apply the same to the whole Organization. This can be very useful when you work with distinct projects, like web applications, smart phones apps, etc.

Next step: take care of security.

(previous step Reading about Enterprise Tester)


Bug statistics are a waste of time

By Gojko Adzic

 new blog post: bug statistics are a waste of time #agile #testing

via gojkoadzic

Agile Planning: My Top Five Tips on Decomposing User Stories Into Tasks

By Mike Kuphal

Blogged: Agile Planning: My Top Five Tips on Decomposing User Stories Into Tasks #Scrum #Agile #PMOT
via mkuphal

Does ATDD = Waterfall?

By Adam Yuret

Fantastic post! RT @AdamYuret New post: Does #ATDD = Waterfall? #softwaretesting

via darren_mcmillan

Revisited – Test Strategy

By Fiona Charles

 Just published: Basics Revisited – Test Strategy & #testing #softwaretesting

via FionaCCharles

Testers are fixing bugs!

By Trish Khoo

 Blogged: Testers are fixing bugs!

via hogfish

A Fair Witness

By Pete Houghton

 Nice post RT @pete_houghton: New blog post “A Fair Witness” #testing #softwaretesting

via adampknight

I’m part of the ‘Now Generation’

By Ewald Roodenrijs

 New blog post “I’m part of the ‘Now Generation’”: #testing

via ewaldroodenrijs

Reading about Enterprise Tester our new Test Management…

Reading about Enterprise Tester, our new Test Management tool. Next days will be great, learning and planning how to put it to work for us.
Since we are working with Enterprise Architect (EA) as a requirements tool, we plan to import requirements from there into Enterprise Tester (ET).

First we need to install it. This is the part I don’t like. It’s incredible how a setup can have so many questions and so many options! If we don’t take the right option we might have to start all over again.

Now things are getting better.
What do I know? I know that we will import requirements from EA and that we won’t use Defects management, because we have another tool to do this. This is a good starting point.