Is your Daily Scrum effective?

If you have adopted Scrum for some time, you have probably worked in a team that has pushed back to have Daily Scrums or that haven’t seen much value in doing so. There are few common reasons that could lead to that situation:

  1. The team sees the Daily Scrum as a daily report to the Scrum Master or another member who attends the meeting
  2. The level of details is not properly set (too many details or too superficial and generic comments)
  3. The team believes they already talk during the day and don’t see a reason to have a formal event for that
  4. and many other reasons…

Those issues can be managed individually by showing the actual value of that Scrum ceremony. However, even if they bought in the idea, how do you know if your meeting is being effective? How do you know that you’re getting practical value from that theory?

Being effective is all about meeting its goals and IMHO the goals of a Daily Scrum should be:

  1. Setting (or adjusting) direction
  2. Understanding how the team is doing to meet the Sprint goals
  3. Understand where we want to be when we meet again

When attending the last TriAgile event, there were sessions and discussions about how to make Daily Scrums more effective. An interesting outcome from that day was the idea of slightly changing the 3 Daily Scrum questions to focus more on what can get done until the team meets again. According to the Scrum Guide, these are the 3 Daily Scrum questions:

  • What did I do yesterday that helped the Development Team meet the Sprint Goal?
  • What will I do today to help the Development Team meet the Sprint Goal?
  • Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

Although these questions help on understanding what was done and what is planned to be done, it does not set short-term (1 day) commitments for each member to pursue and to get things done. You can easily say what you’ll do until tomorrow and have nothing actually done by tomorrow. What if instead of saying what you will work on you said what you’ll get done by tomorrow? It’s not about sharing what you’ll do. It’s about sharing which small increment of value you’ll be completing until the next meeting. With something simple like that you can change the perception of Daily Scrums from ‘reporting/planning’ to ‘achieving’. That will also force your team to have smaller tasks that can be done in a day or so.

Having said that, see below the suggested questions to make your Daily Scrum more effective:

  • What did I say yesterday I would get done to help Development Team meet the Sprint Goal?
  • What will I get done today to help the Development Team meet the Sprint Goal?
  • Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

Give it a try and share your experience!

Rails 5.0 is available!

It’s been 7 years since I had my first experience with Rails. Back in 2009 the version was 2.3.x (I’d guess 2.3.5, but not sure) and managing gems during that time was such a pain. Since then we got many different versions with features, bug fixes, security and performance improvements (yes, per-for-mance, if you’re still one of those skeptical haters that think Rails can’t perform/scale).

Last June 30 version 5.0 was released and it has few interesting features.

  1. Action Cable: A brand new framework for WebSockets. If you need to keep a connection open between a Web client and the server, that can be very handy. It’s definitely worth to take a look at.
  2. Puma: Instead of Webrick the development environment now comes with server by default. Personally, I was never a big fan on Webrick. Making Puma the default server turns the development environment more professional and in case you need other devs accessing your env, it becomes less painful.
  3. Turbolinks 5: New version of Turbolinks. Great feature since developing mobile versions is a requirement for pretty much any app.
  4. API mode: This is the cherry on the cake, IMO. Creating a RESTful API skeleton has never been so straightforward. If you need only a backend app to respond some REST calls spitting JSON, that’s the way to go. By providing the –api parameter (rails new backend –api) you can create a basic backend app structure.

Give it a try and spend some time playing with it. Further sources can be found at the official page.

Add labels when creating issue on JIRA

JIRA is definitely a flexible bug tracking tool and one of the most powerful features is workflow customization. This post describes how to add a label automatically when an issue is created. This can be useful when you want to flag an issue and later capture that in a filter or board. A practical example is to flag Bugs that are created so that they can be reviewed during Bug Scrub meetings. In order to add a label we need to add a custom script in a post-function.

  1. As admin, go to Administration >> Issues >> Workflows >> Click on Edit in the workflow you want to change
  2. Click on the ‘To Do’ step (assuming your workflow is the default one)
  3. Click on the ‘Create’ action >> Post Functions tab >> Add post function
  4. Select Script Post-Function >> Custom script post-function
  5. Paste the following code snippet replacing ‘BugScrub’ by the tag you want
  6. Publish the workflow => Important: If you don’t publish the draft workflow, no changes will be reflected.
import com.atlassian.jira.ComponentManager
import com.atlassian.jira.issue.label.LabelManager
import com.atlassian.jira.component.ComponentAccessor

def user = ComponentAccessor.jiraAuthenticationContext.getLoggedInUser()

LabelManager mgr = ComponentAccessor.getComponent(LabelManager.class)
mgr.addLabel(user,, 'BugScrub', false)


For additional information about the addLabel method, please refer to the official documentation.

WAS operator in JIRA

JIRA is one of the most used bug tracking system and one of its main features is the search mechanism. There are two modes when searching for issues on JIRA: Basic and Advanced. The basic one is composed of a set of filters you can select and define values. Even though the basic mode is enough for most cases, it does not allow you to run some more complex queries.

Today I’ll present the WAS operator that can be used by writing JQL queries in Advanced mode and that allows you to search for issues based on the property values in the past. This can be extremely useful if you want, for instance, to collect history data or to evaluate changes against to such a property.

This operator can only be used with the following properties: Assignee, Fix Version, Priority, Reporter, Resolution and Status fields only.


Find all bugs that were open last week

issuetype in (Bug, Defect) AND resolution WAS IN (Unresolved, EMPTY) before endOfWeek(-7d)

Find all stories that were resolved last week and that are now closed

issuetype = Story AND status WAS Resolved DURING (startOfWeek(-7d), endOfWeek(-7d)) AND status = Closed

Find all stories that were unassigned in the last two days 

issuetype = Story AND assignee WAS EMPTY DURING (endOfDay(-2d), now()) AND assignee IS NOT EMPTY

Should I plan future Sprints?

I’d like to cover one topic that may be a little controversial among managers or agile practitioners: whether planning sprints in advance is acceptable or not in a Scrum project. Should I plan only the Sprint my team will start or should I plan future Sprints?

Being agile is about identifying and reacting to problems as soon as possible. The three pillars of a Scrum project emphasize how to do that by inspecting, adapting and being transparent during the Scrum events. However, there is no Scrum event to go beyond the planning of the current Sprint. This is why the most purist people don’t plan future Sprints.

Even though Scrum guide does not mention this, positive results may be realized when planning more Sprints in advance. These are some benefits of doing that:

  1. Anticipate problems that require immediate actions
  2. Increase likelihood of meeting external milestones (i.e. those that do not depend on or cannot be controlled by Scrum team)
  3. Identify need of hiring new people for the team

However, how can this be done without impacts (or with minimum impacts) in the current sprint, since team members should be focused on developing the scope of the Sprint?

Slightly change Backlog grooming sessions can be a good alternative. During grooming sessions the Scrum team and the Product Owner discuss about the Product Backlog with a clear goal: finish the meeting with an improved Backlog. The definition of “improved backlog” can vary from team to team, but usually attendees focus on detailing more the user stories and their acceptance criteria. However, these sessions can also be used to create sub-tasks, to estimate and to assign them.

With a Backlog with sub-tasks and their estimates, the Scrum Master can distribute Product Backlog items in the future sprints, based on the Product Owner prioritization. Having done that, it is possible to check if some milestones look feasible, if people are over-allocated, which may require hiring new people to meet some dates and features, and so on. In addition to this, having 1:1 meetings between the Scrum Master and each team member, once a Sprint for 30-60 minutes, to review estimations and assignments improve the accuracy of the Backlog. This would require an additional effort for the Scrum Master of about 8 hours / sprint, considering a 8-member team, as well as a total of 8 hours when summing up 1 hour of each member. This can be an important practice to mitigate risks.

Important: What is planned for future sprints is not a commitment. A Scrum team can only commit to a Sprint goal after the Sprint Planning.


Understanding a way to creatively think

‘Being creative’ is a skill that many companies require employees to be, but sometimes neither the company nor the employee have a basic understanding on how to leverage a creative thinking. For the last few weeks I’ve been taking a Coursera course (On Strategy : What Managers Can Learn from Philosophy – PART 1) and Luc de Brabandere shows a simple but effective way of differentiating when you are thinking about something new or when you are just applying logic or past experiences.

Human beings apply models to solve a problem, i.e. they make a simplification of the problem and try to fit it in a pre-existing box that may have address a similar issue in the past. Basically, when we see a problem in the world, we pick one of the models in our mind and then we come up with a proposal of solution. This is called deduction and is the most common and faster way of thinking, since our brain is ‘lazy’ and tries to follow the shortest path to answer such a question.

However, creating something new goes a way beyond of only applying pre-conceived models. Inventing something is more related to analyze a real-world issue and then come up with a new model for handling that. This is called induction.

Deduction vs. Induction


To exemplify, think on how to categorize the following words:

  • Rio de Janeiro
  • San Clemente
  • Dallas
  • Rome
  • Washington DC
  • Jeffreys Bay
  • Buenos Aires
  • Miami

You may think about separate these cities in two groups: capital or non-capital. Or maybe in US cities and non-US cities. Thinking in this way, you are applying models you have on your mind to solve the problem of categorization and that are widely adopted, what makes your brain bringing them firstly. This exemplifies deduction. However, if you try to think out-of-the-box, you can come up with a new model (at least for you) to separate cities that 1) are in the coast and which name is composed by more than one word and 2) cities that does not satisfy the aforementioned condition. This is an example of induction.

The very first step for creatively thinking may be to understand when you are deducting and when you are inducting, so that you can switch them when necessary. Both deduction and induction are important and compliment each other. Although induction is not the approach adopted by us in most cases, training our mind may help us to be more creative.

If you get interested about this topic, I’d suggest you to take the Coursera course to go deeper. Thank you.