Creating your Scrum Cards – Free Template

Hi :)

So after writing about how I prepare my templates (Creating your own Scrum Cards) for the team to write down User Stories, Bugs, Tasks and Improvements, I got some requests to make my template available.

So here it is : US-Bugs-Task-ToPrint (excel format).
Normally I print them using the coloured paper I want (the colours I use are in the Sheet name) and then just cut them in batches using a paper cutter.

In case you you don’t have coloured paper you can just fill out the cells with the color you want and print it in a Color Printer.

Hope it makes your life easier :)

Let me know if I can help you or provide something useful for you.

Creating your own Scrum Cards

Hi!

Quick Tip Today: Creating a User Story Card

You can use index cards and write on them, of if you are like me: a bit lazy but you like things pretty visible and kind of organized, you just have to do some tuned cards in a text editor (Word for 75% population), print them in different coloured paper and.. cut them :). They will them be the basis for your team to use in the
Sprint backlog.

Let me then share my experiments with my tuned Scrum cards.

Scrum Cards – Colour protocol

- Red (or pink when there is no red) for BUGS
- Green for improvements (of previous user stories)
- Blue for tasks – (User stories are broke down into tasks)
- White for User stories (US)

Scrum Cards – The templates

I create a template that I can print because I found most useful to have already in the card the following:

1- USER STORY card:
- User story number (if using a electronic Prod. backlog, you want to refer to the ticket number)
- US component- where this US fits in the big picture of our product
- Priority – we always start by working on most important US
- Estimation – the estimated Story points for this US (just for reference actually)
- UX – name of the Designer who created the concept, just in case we have a question (when having different UX people working with your team)

Looks like this:
USER STORY card

2- Task card:
- User story number (if using a electronic Prod. backlog, you want to refer to the ticket number)
- Estimation – the Estimated effort for this task
- DEV- the team member(s) coding it
- QA- the team member(s) testing it
- REV- Revision number – in which release we can test and find this task

Looks like this:
TASK card

3- Improvement card:
- Same as Task, but ..it’s a green card :)

Looks like this:
IMPROVEMENT card

4- BUG card:
- BUG number (When using a tool to track bugs you want to refer to the ticket number in the tool)
- Component – to which component this bug belongs
- QA- the person that found the bug (important in case we have doubts how to reproduce and also to ask the person to re-test when fixed)
- DEV- the team member(s) fixing it
- REV- Revision number – in which release we can find the fix and test

Looks like this:
BUG card

Hope it Helps!

Older Posts that may interest you:
- Creating Sprint backlogs (Scrum boards)
- Dealing with Legacy Bugs- the BUGLOG

Dealing with Legacy bugs in Scrum – THE BUGLOG!

Hi!

After writing about Sprint backlogs – how you can create one and why it should be the big elephant in the room, I remembered we rarely see people talking about the nasty legacy bugs the scrum team gets during the sprint and how to fit them inside the sprint.

First a disclaimer: when I say bugs, I do NOT mean bugs from the User Story (US) currently being implemented by the team. If the bugs you find are related to the US in progress, then these bugs are part of the current work, part of the current sprint scope. So, when I say Bugs in this post I mean bugs that we have from previous User Stories, from Legacy code.. bugs that don’t fit the current Sprint Scope.

Have you asked yourself several times how to fit legacy bugs in a sprint without endangering the commitment? if yes, then this post might help you.

Scrum
Scrum framework has a very well defined rule regarding injection of “not committed” work: you don’t inject.
If you really need to do something not planned, then you abort the sprint and re-plan. This obviously makes a lot of sense, team has committed for a certain scope withing a fix period, if you add stuff and the time is still the same..well.. no can do. Abort and Re-plan a new Sprint.

Nevertheless this beautiful simplicity of Scrum, we know that life is sometimes not that easy and if a customer is complaining about a bug we should handle it and fast, so how can we do that without endangering the current sprint commitments and at the same time without aborting the sprint and re-plan everything again?

Handling Bugs in a Sprint

The way I found to handle this bugs was to create what I call the BUGLOG.

First step is both team and PO agree that one team member (or a pair if you have lots of bugs and need to keep knowledge in same level) will only be available to fix bugs during the sprint. Nothing else, just bug fixing. By one person, I mean any person, you don’t have to assign one team member in particular, the team members will assign themselves daily according to the bugs in the BUGLog.

As you break the stories into tasks and build your backlog during sprint planning (in order to find out what can you commit to), you will consider team availability equal to Team availability MINUS 1 team member.
Example, if your team has 8 people working, and decides to have 1 person for bug fixing, the team availability will be 7 people.
If you base your commitments on your velocity only, then you should commit to a bit less than your average velocity, because 1 person will be “out for bug fixing” :)… consider it has if each day the team has 1 person off for vacations.

Now that you did your sprint planning and you know which user stories you’ve committed, it’s time to build the BUGLOG:

The BUGLOG is a second board, placed next to the Sprint backlog, having the TOP 10 most important bugs – the one’s that need to be fixed first (I use TOP 10 or 5, but it’s actually up to your team and PO to decide… if they are all minor fast-fixing you can have more, but for the sake of simplicity and quick visualization, keep it small… you can add more at any time!).

Team Members assignment to Bug Fixing

At this moment the team has it’s Sprint Backlog, with the committed Us and it’s BUGLog with the most important/ urgent bugs.
The same way the team looks at the sprint backlog and each team member assigns himself to a task (by picking a task which the team defined as priority in the current goals) the team also looks at BUGLog and checks current priorities. According to those, someone from the team assigns himself to do bug fixing that day.
(From my experience the self- assignee is normally the person that knows more about the bug or the area where bug is).

It is really important to repeat this : Everyday the team looks at the list and agrees on who will do bug fixing. Somedays the person from previous day decides to continue doing bug fixing because it makes sense. But the rule is that we all have our share of bug fixing.

We have now the team working in the Sprint Backlog and this Special Bug-hunter-of-the-day team member fixing bugs. Starting by the one in the top of the list and having as goal to fix as many as he can during that day! (you can even propose a contest ;) for the Mightiest Bug Hunter).

Team Synchronization
The assigned Bug-fixing team member should also be present in the team daily scrum. First because the next day he will be back to Sprint backlog tasks and second because it’s important for the rest of the team to know which important bugs were fixed.
My experience: I’ve always carried on the Daily stand up as usual, team members talking about their Sprint backlog tasks, impediments and together defining what to do next (team daily planning). The Team member doing bug fix would be the first or the last to speak during daily standup, about bugs fixed and any doubts or help needed to carry on next bug. We would ask this person to be the first or last talking because that way we wouldn’t break the flow of conversation around the sprint backlog when the other team members start speaking. But nevertheless this small thing, the BUGLog is seen as part of the overall team scope, just with the slight difference of being handled only by one person each day.

Deciding Bug Priorities

As the list gets smaller, with the bugs moving to Done column, the PO will decide which are the next most important bugs.
(In one of the teams I worked with, the PO received every morning a report from an offshore quality team with all new found bugs. In this case the PO would, every morning, look at the current list of ‘Not yet being fixed bugs’ and look at the report received from quality, and decide if there was any new bug more important than those already in the BUGLog. I so, then he would re-order the bugs.)

Conclusions of my Experience

This BUGLog actually proved to be a great solution to our needs:

1- Legacy bugs are fixed
2- You can also use this BUGLog to add small improvements in older stories or deal with technical debt if/ when that is your biggest pain point
3- PO’s are happy cause they see stories being done and bugs from the past being fixed, all leading to a more stable solution for our customers
4- Team is happy cause they don’t feel interrupted from their work in US and they can still fix nasty bugs they are worried with
5- Scrum master happy too, less yelling (kidding) ;), less: “we need to replan the sprint cause if we need to fix all that, we can deliver our US” and feeling of more trust between PO and Team, cause this system allows both to do what needs to be done without anyone feeling that unplanned things can’t be handled.

For me this proved to be a win-win situation, a tradeoff between both the Team, Po, current customers and..future customers.

Hope it helps you as much as it still does help me and my teams!

Happy easter :)

About Usefulness

This one will be short. Just want sharing something I just found out.

I realised every time I get up of my desk to pick up a water, a coffee, go to the printer, whatever.. I always also find someone looking for something, and meanwhile I also found out that I always manage to help those people by providing, replacing, solving or just suggesting another way/ perspective. How do I do that? I quite don’t now.. I guess I perceive and then listen and .. Puff! Done.

Along with that, I just realised that this is what I do best and that this is exactly what I fracking love to do. Solve problems and be useful to people when they need it.

I’m glad I found that. I just solve myself a big problem.

Carpe Diem!
Cátia

Building your Sprint Backlog / Scrum Board

Hi :)

Today a practical tip for building a Sprint Backlog aka Scrum Board.

Why should we have a board?

The board main function is to allow team to visualize remaining work (tracking) and facilitate daily synchronization (Re-plan).
Everyday the team gets together, looks at the board (which contains the committed work) and the team re-plans it’s day – What should we do today in order to accomplish our goal?

Because of this, Scrum Boards should be:

• SIMPLE – don’t add to much columns and stuff not needed
• BIG – Everyone sees it, knows where it is and just by looking knows where we are (regarding the team goal)
• ACCESSIBLE – everyone can see it and update it – by everyone can update it I mean the team (it’s their plan, they own it)
• FLEXIBLE – should be easily improved and adaptable to team needs
• INTERACTIVE – appealing people to touch it and play with it (example, by moving cards from one column to another) – if you touch it and name it , you own it – yes, tasks are like puppies.
• VISIBLE – the kind of : you can’t avoid it when entering the room – a good way of keeping questions answered without pressuring or interrupting the team

Paper or electronic ?

I say: something real you make with markers – so paper or whiteboards.

I can give you at least 3 reasons to stick with a physical board rather than using some electronic version:

1.  Electronic boards are accessible, but they are not visible (unless you can afford a big touch screen and display it in the middle of the room)
It’s true that everyone can access a drive or tool, but it’s not something you see just by entering the room. You have to log in, or search inside a folder, so it’s “Hidden”.

2. Electronic appeals to individuality – paper leads to collaboration

If you have a tool:

- you’ll update your tasks before the stand up for the sake of speed – with this you loose interaction

- or you’ll do it during the stand up- with this you’ll increase the time of the daily stand up (and create waste time)

If you use paper, you can speak while you move or edit it. Everyone around you, listening, will also see the task you are talking about

Just FYI, Science :), that Lovely Lady, says there are 3 learning styles:

a) Visual Learners (say around 60% people)
b) Auditory Learners (around 30% people)
c) Kinesthetic (tactile) Learners (around 10% people)

for more details check Neil Fleming’s VAK/VARK model and here .

This means that if you use a real board on the wall, people will not only listen but also SEE what you are talking about, and as you move your tasks through the board, you’ll also touch, perceive the tasks as something material, something that exists.
So with a simple board on the wall you can reach everyone’s attention.

3- There is nothing easier and simpler than paper/ boards to work with, update, improve erase, add…

By using a tool you are bound to what they have, or in case it’s your own tool, you’ll need to implement extra functionalities (and test it, and train people, and…) – while you are getting the budget or permission for this, I’ve meanwhile created zillions of boards with my team ;>.

So my advice is Stick with paper or whiteboards. Use it, improve it, reach the best possible solution. Then, if still you want your own electronic gadget, then… go for it and good luck :).

My board as an example

I made a draft of the board we use. – Sorry but I just can’t take pictures of our walls due to product confidentiality reasons. So if you like it/ find it useful you can just reproduce it in big size
(Extra Tip: don’t make it toooooooo big, else as it will look ‘empty’, everyone will feel tempted to add more tasks than those that can be handled).

If you get back to the basics, Scrum boards have only 4 columns: User stories, Not started (tasks), Ongoing (tasks) and Done (done done, no buts-> done as in ready to go live).

Although I love simplicity, I’ve faced teams where QA was a bit forgotten. So we had to make this visible in order to deal with it.
These teams had no QA experts and developers would run away as much as possible from testing. When having just Ongoing column, tasks just stayed there in a kind of limbo or would go to Done without being really done.
So we split ‘”Ongoing” into DEV and QA.
Having these columns was the way we found to show exactly what was under testing and when this column grows bigger everyone knows it is time to jump in and do some testing.

You can have it or not, it’s up to you and your team. Some teams just create testing tasks and take them through the flow-> Not started->Ongoing-> Done. – Been there, done that – Works perfectly, but only if you have someone caring about QA inside the team, else, again, everyone will delay those tasks as much as possible.

My advise is: don’t get influenced by anyone, except by your team : Do what your team needs and then keep improving it. Target simplicity and transparency and all will certainly go ok.

Let me know if I can help you building your board or just share your own with me ☺ I appreciate new ideas!

Being a Coach

Hi :)

Here are some thoughts, based on my experience, about being a coach.

I realized it’s not about technology, processes and frameworks.
It’s not about teaching people how to do stuff, although it helps if you can show them a new way or help them finding a solution.
But that is not at all, the most important thing about coaching people.

Coaching is about inspiring.
People are smart enough to study stuff and find better ways of doing their work, but only if they are motivated to do so. Or if they realize they have a need and that they must create their own time for personal and professional growth.

My experience says that if you want to be a good coach, you need to: inspire people

Inspire so they feel motivated and eager to come to work
Inspire so they feel worthy, useful.
Inspire so they feel eager to learn.
Inspire so they feel HAPPY and FUN.

Inspire people to do and be better, to be all they can be, because that’s all they need: inspiration. Just a little push. All the rest they can handle it pretty well. And, oh boy!, once inspired you can’t imagine the potential ahead of you!

And last, but not least: Inspire them to be empowered.

Empowerment – not given but taken
Empowered people can change the world, or at least the things they touch. But empowerment is a tricky thing.
Most people, maybe due to education or culture, think that empowerment in a business environment is something that must be given by someone having a position of power. Meaning, if you are a developer you feel like you can only be empowered if you line manager or technical lead says so in front of everyone else.
This is not true. This is not empowerment- this is task attribution or delegation.

Life in an office is not that much different from life in… well, life.
As such, empowerment is not given but rather taken (taken as in assumed not taken as in steal for someone).
Once you put your mind to solve something in your personal life, there is no one who can stop you as well there is no one who can actually give you the energy and will power to do it, except yourself.
Same in office. You should not expect to be empowered, you should take the chance to change or do something and embrace the power and greatness of doing it. Take it, don’t wait for it.

Really powerful people are not in a power position, they make it. They are the one’s you recognize as leaders, opposite to those you consider just silly bastards with illusion of power, the one’s you comply with but whom you’ll never follow wholeheartedly.

Gandhi was a powerful person. And he did not have any high position in the hierarchy of kind lawyers, he was not DR. PHD Master MBA Mr. Gandhi. He was powerful because he chose to be so, he took every single chance to make the difference and change people’s life and or mindset.

It’s up to you to be powerful. It’s up to you to be different and drive for yourself your own path. If you choose to do so, then, you might as well consider yourself a coach.

What about people who don’t want to change?

Yes, they exist. Sometimes out of fear, sometimes envy, sometimes ignorance, but yeah, they are out there. You can bring knowledge to people, but only if they want they will learn. And some, let’s face it, just don’t want to. And that is ok. If we were alike and all inspired people, life would be boring and expectations too high.

So, Know when to give up. Some people don’t want to change and they won’t let you do it. Just go and use your energy somewhere else. You deserve it, as well as all the others waiting for you to arrive and waiting for the chance to evolve with you.

Expectations

Expectations are good, they drive you. They help you aiming and they lead you there.
But, on the other side, expectation can also be a time bomb in your hands.
I’ve always had problems managing both my temper and my expectations. I’m not a patient person, so it’s really hard for me to contain my expectations to a sane level.
If, on one hand, this is good because it helps me eager and open for growth and new experiments, on the other hand it’s a big problem because I may never be satisfied with what I’ve achieved.

So, my personal advice, coming from my own pain, is: Plan your expectations.
For example: Write them down in a paper whenever you accept a new goal. Then, just track them down. Once you’re done or the time is up, you’ll know where you are and how far you are from your initial expectations.

Things will evolve and I really hope you add more and more expectations to that plan of yours, but the point here if for you (and me) to be able to look down to that plan, and know that your achievements are actually good, and although it may feel like they are not, you’ll (we’ll) know that this is only our big-mouth expectations talking and trying to trick us by overlooking what has been achieved.

I once heard a sentence from a writer I never forgot, because it makes a lot of sense on my way of living, he said: It’s extremely arrogant and hypocrite to judge the past, having the advantage of being in the present.

This is how I always managed my expectations. I would judge what I did, but having as basis my current mindset. And that is wrong. I should always fit the results into the expectations defined at the time and considering the situation when they were set.

I did that, now I won’t do it anymore. I learned and now, I know better.

Have a nice weekend, and, please… Go make the difference is this little world of ours.

Leaders and Servants – Tips for the Scrum master

Scrum masters are not meant to lead (lead technically or in terms of business), they are meant to serve. And serving has different flavours.

This ‘epiphany’ started with a 15 seconds chat with a fellow Scrum Master.

- ” Should you be a leader? “- I asked the scrum master

- ” Of course”- He replied

- ” Will you drive the team?” – I asked

- ” Of course, I must drive them to do better”

And here I disagree.

It’s too easy to lead and drive (easy for those who really are drivers and leaders, for the others: this post is not meant for you).

Too easy to make people follow. And good too. But only if you mean lead and drive their motivation, engagement and pride.

So I say – Scrum masters are not meant to lead (lead technically or in terms of business), they are meant to serve. And serving has different flavours:

When you start as a Scrum Master (I call it Type 0) in a new team you serve as the person who helps removing impediments, you serve as the person who helps organizing the work, serve as facilitator on running events as daily scrums, retrospectives, demos and by setting up practicalities.

But for me this is a first level Scrum Master. A servant of practicalities. You won’t grow a team with this, you are just keeping things clean and neat.

So here comes my favorite flavour: The Scrum Master.

- The one who causes pain by uncovering what’s wrong  and does not heal people by making small patches that hide reality or solve temporarily stuff (does not loose time fixing symptoms) .
- The one that, above all, believes that the team must heal for itself no matter how hard, how painful and how long it takes. For every fall you take, you will rise stronger. And this is true also for teams.
- The one that believes, that knows!, that each team is smarter than any Scrum Master in earth and they’ll find better and or most suitable solutions for their own illness.

I guess this is why Scrum Master as troublemakers for some. These little bastards keep pointing out your problems and they don’t let go until you fix them.

I’ve had my count of type 0 Scrum masters, so nice and protective. Always keeping things neat but unfortunately with no impact on the team growth. Sometimes it’s also because it’s really hard to justify where a Scrum Master spends it’s time, so we do this neat boards and cards and things (which are ok and needed, but nor what teams need the most). How do you explain and justify that 100% of your time relies on observing the team, making questions and reading? That’s waste, right? May be. But, isn’t it needed?

I also had my share on type 0 too. Now I guess I don’t care anymore. I dedicate myself to do silly and hard questions. Of course that I still try to do (as much as my skills let me) neat boards and things to increase visibility and transparency, but if they don’t use them, that means they see no value, so I stop. Ok, there’s a minimum you must keep, but what’s the point of doing stuff for people if they can’t fully use it? We should be helping with answers not more waste, right?

And the only way I know to help with answers is by making questions.

Are you helping with questions or giving the answers you want to see? Is that the answer they need? How can you tell?

Sometimes we know the team needs something, for example, to do a brainstorm and get a common understanding by sharing different perspectives, but  it happens that they don’t feel they need it. That’s ok. If you know you are right, just prove it. Show why they need it, make questions that will help them figure out that actually they need to do something.
But don’t just recite the books you read: they are smart enough to give you all the arguments to prove their reality is different, and how your suggestion doesn’t fit.

Question everything, maybe even suggest a way and ask them to experiment it – you’ll probably end up with a new way of doing stuff: a better way for all.

Bottom line, don’t try to be a leader. But also don’t be just a team assistant doing practicalities. Observe, question, suggest, try. Be a servant. A servant of pain and doubts. Make them think out of the box, new perspectives, new ways.
Don’t be a driver, just show them how to hold the wheel if they need too. show them how it can be done, don’t trap yourself on thinking that’s the only way of doing it. Let them evolve.
And scream, scream a lot while you are all taking a ride with them driving, they’ll surely improve the way they drive just to shut you up. My dad tried that and it worked ;) I’m a better more confident driver now, and he… well he sleeps while I’m driving.