Seek understanding – not insurance

When you communicate, you have two responsibilities:
1. communicate your message
2. ensure the message is understood

#1 is easy – but it is #2 that counts.

You can do #1 and forget or skip #2 – but you haven’t really communicated. Saying words out loud is not communication – it’s just making noises. Communication implies an understanding from both the initiator and receiver of the communication.

You can also do #1 in such a way to make sure that #2 doesn’t happen – that’s called covering your arse.

Change the unchangeable

In an environment where so many people avoid decisions, shy away from responsibility and avoid asking hard questions, the people who do this well stand out.

Shake a few trees. Take a risk and raise a tough issue. What’s really stopping you? What are you afraid of?

Politics? Don’t want to make an enemy? The times in which trolls and power seekers can gain influence without creating and delivering are slowly but surely coming to an end. The Internet has relativised the playing field, and our creations and art speak for themselves.

Afraid that you’ll look silly or uninformed? If you raise your hand you will almost certainly be wrong from time to time. Maybe even often. But recovering from being wrong with grace and dignity and learning from your failures is far more valuable to you and those around you than sitting silently.

Do you believe it’s unchangeable? That the status quo is unquestionable and immutable? It’s not.

True, you want to pick the battles you can win. But pick one. Try it. Look around you, and pick one thing that has been bugging you but you have always considered unchangeable – then change it.

Shooting the messenger

Sometimes you have to choose between two or more bad options. Often the perfect choice is a luxury that you can’t afford.

The question is how you respond to this choice, and how you communicate it to your team. I believe you have two options:

• You can act purely as a messenger, or
• You can take responsibility and ownership of the decision, and explain to your team enough of the background to the decision that they understand and accept it.

It’s easy to go with option 1 – to throw up your hands and say “well it wasn’t my decision” – it’s always easier to be a victim – but option 1 is poisonous because it builds in your team an inherent distrust of management and a dissolves belief in your product strategy. And in the long run, if you always play ‘the messenger’, your team won’t only lose faith in your company, they’ll lose faith in you.

Option 2 is hard… but get it right, and it’s art. And sooner or later the messenger gets shot anyway.

Meeting etiquette

You arrive in the meeting room at 9:58am; the meeting is scheduled for a 10am start. You look around the empty room and wonder, “Am I in the right room?” You check the meeting invite on your blackberry, but sure enough, you’re sitting in the correct place. As the clock ticks over to 10am, you’re still sitting there alone, thinking about the emails you haven’t read and the report you haven’t finished. At 10:03, the door opens a crack and Bob sticks his head cautiously through, the look on his face asking “is this the right room?” He sees you, smiles, then opens the door fully and comes through. “Phew, I’m not late”, he thinks. Bob sits down across from you, opens his laptop and starts clicking away.

Over the next 5 minutes a few other people come one by one through the door, until at around 10:12 Dave, the meeting organiser, comes rushing through the door in a flurry, laptop in hand. “Sorry everyone” he says, “I was stuck in another meeting.” Dave opens his laptop and turns on the projector. As the projector shines it’s faint blue glow on the blank wall, you see Dave looking frustrated and clicking repeatedly. The projector won’t connect. “I think I have to restart my laptop” he says. Six minutes later, approaching 10:20, Dave starts the meeting.

There is no agenda, so you’re still a little unsure what the meeting is about. It turns out however that Dave isn’t too sure what he wants from the meeting either, and the discussion starts to turn in circles. Bob and Susan are discussing something separately, you can’t quite tell as you can’t really hear them over the other voices in the room. Suddenly you hear a phone ringing, and Mary reaches into her bag for her mobile phone, answers it. At 10:40 Mark stands up and announces he has to leave, he has another meeting. When the remaining attendees pile out of the room at 10:58, there are no action points to take away, no follow-up discussed, no one has recorded any minutes, and you still don’t really know what the meeting was about. The last to leave the room is Henrik, who has not said a single word since entering the room, but who has probably replied to at least 15 emails.

A good meeting can be an amazing thing: a group of minds with a common goal coming together to achieve something.

The problem with meetings though is that so many of them are “bad” meetings. We’ve all been in our share of bad meetings, and we know what a bad meeting is… A bad meeting is a waste of time, productivity and money.

For many people, it is not unusual to spend more than 4 hours a day in meetings. For some, it is even more. I regularly spend up to 75% of my normal working hours in meetings. With such a large time investment, it’s important to me that meetings are as efficient and useful as possible.

Here’s my list of dos and don’ts for having a worthwhile, efficient meeting:

• Be on time. You should be able to plan your day to let you get to where you need to be by the time the meeting starts. If you know you will be late, it’s polite to let the meeting organiser know beforehand.
• If you have to leave the meeting early, say so at the start of the meeting.
• Pay attention – don’t read your emails or work on other things. It’s disrespectful and distracting to the other people in the meeting. It’s also incredibly inefficient if things need to be repeated because you were busy emptying your inbox.
• Leave your laptop lids closed – if you need your computer to take notes, then you should just be taking notes.
• Turn your phone off or put it on silent.
• When you’re in the meeting, stay in the meeting. Don’t run in and out every 2 minutes for a call or to talk to someone. It is distracting for everyone.
• There should only be one conversation at a time.
• Stay on track. If side discussions come up, then make a note and take them offline.
• Be involved. If you are at a one hour meeting and you don’t say anything, then what value have you brought to the conversation? Why were you there in the first place?

As the meeting organiser:

• Set a clear purpose and goals of the meeting, and distribute beforehand.
• Set an agenda for the meeting and distribute beforehand.

Ask participants for comments or additions to the agenda.

• Act as a timekeeper – and stick to the time.
• Record the minutes from the meeting and distribute afterwards. Include clear action points.
• Make sure there are clear next steps discussed and decided upon at the meeting.
• Invite the right people and not more than that. As the number of attendees in a meeting increases, the efficiency decreases.

Special tips for voice conferences:

• Be on time – it is just like any f2f meeting. When you turn up late, it is distracting for the others on the call, and wastes everybody’s time.
• Choose a quiet spot where you have good reception. If there is background noise near where you are, then try to go on mute when you’re not speaking.
• Pay attention! Don’t write emails or work on other things in the background.
• Never attend a voice conference when you are in transit on a public train, in a car, or worse, walking down the street. It is noisy, distracting, and you can’t really focus on the conversation.
• At the start of the call, everyone should have a short 30-second “check-in” to announce themselves. A check-in could be a very quick hello, an update on how things are going for them, what they have been doing, etc. This makes it easier to be able to involve yourself in the call later, and ensures that everyone can “be involved” right from the start.
• If telcos are a constant part of your work life, then it pays to invest in good voice conference equipment. There is nothing worse than dialling in to a conference with a collection of people in the room on the other side who are impossible to hear or understand.

Using smileys in business emails ;-)

Smileys can make a big difference to how someone interprets your email. A well-placed smiley can soften a piece of criticism, can add a friendly tone to a request (or demand), or indicate that something has been said intentionally sarcastically.

Since the birth of email, people have been aware of the dangers of relying on only the written word for every day business communication. In emails, words can be misinterpreted, subtelties lost, and tone or intentions misunderstood. It’s true that this can be the case with all forms of communication, but email is especially susceptible.

Emoticons are for many a tool for overcoming these weaknesses of emails. Where a sarcstic remark is made that is intended to be funny, then add a tongue-in-cheek smiley ( :p ) to make sure people get the joke. When something funny happens, then laugh about it – ( ). If something is just to be between you and the person you’re writing too, then add a winkey ( ).

Kenneth Davis believes Emoticons are a natural evolution of language. He makes the point that when the question mark first came into use in the 9th century, and the exclamation mark around the 15th, there were undoubtedly many scholars who found them cumbersome, ugly and unneccessary; however, over time they were found to be useful additions to the language, allowing writers to express themselves and convey emotions and intent more effectively. In the same way, Emoticons have evolved to allow us to better express emotions and feelings in our written communications.

The belief that emoticons are uncecessary or ametuerish replacements for using clear and descriptive english to be understood belongs to the time before we were all writing to each other every day. In the modern business environment, most businesses rely on instant communication to operate – emails, instant messenger, and the like. Email has, to a large degree, replaced personal spoken conversation in the modern businessplace. (Whether this is good, bad or other is a topic for another time.)

In the past, written communication was in the form of letters that were carefully drafted, typed or printed on paper and then posted. You expected that the letter would take at least a few days to arrive to the intended recipient, so there was no sense of urgency with written communication. If something was urgent, you would use the telephone or talk to them in person.

Today, with the increased adpotion of email, instant messanger applications, SMS and other forms of instant communication, we can see a merge between written and spoken conversation. From a style perspective, modern communications writing is more like spoken communication, rather than traditional written style. A formal written style still exists, as does the spoken style – but we have a third and new style – let’s call it the “instant written” style.

It is also worth noting that when it comes to business emails, berevity is important. Emails need to be short, concise and to the point, and it is much often much shorter to use a smiley too indicate how you feel about something rather than to use words to describe it.

There are times, naturally, when emoticons are not appropriate. I would not use one in a formal business report, or anything that was intended to be printed on paper. An emoticon does not belong in an email to the CEO of your company, nor does it belong in a first email to a prospective client. However to proclaim that they are the amatuerish, show a lack of vocabulary or a limited grasp of language is an antiquated, pretentious and most of all snobbish attitude, IMHO.

Quality Assurance is not Quality Control

Something that I see people confuse all the time is the difference between Quality Assurance and Quality Control. Many organisations seem to use the terms interchangeably, and most don’t seem to recognise the difference between the two things, but they are very different concepts, and both are required for the ultimate success of a software project.

So what’s the difference?

Quality Assurance

Quality Assurance (QA) is a process, and it covers the entire software development lifecycle (SDLC). It is a series of activities, controls and processes that aim to ensure that the software is built to the right level of quality from the start and that it will meet the project objectives and specifications at the end. QA is preemptive and planning based.

Quality Control

Quality Control (QC) is a set of activities designed to check that the software has been developed correctly, that it is free of software errors (bugs) and that it meets the specifications to an acceptable level of quality. QC is reactive – it is a control measure to check the work of the previous group before it is released.

An example

Let’s assume we work in a beer brewery. This brewery produces beer in 330mL bottles. At the end of the production line is a guy who’s job it is to check that the bottles are full and don’t have anything other than beer in them. He stands on the conveyor belt and checks each bottle as it goes past, removing those with problems. That is Quality Control. He doesn’t have any influence on how the rat got into one bottle, or why another bottle was only half full – he can only report those problems and return the product to the producers.

Elsewhere in the brewery there is a guy who’s job it is to make sure that no rats get into the bottles in the first place. He does this by monitoring the entire brewing and bottle-filling process, looking for any parts in the process where rats could potentially get into the bottles, and altering the process so that it is no longer possible, or at least less likely. When he deals with the rat problem, he might look at why bottles only get filled half way, and modify the process again. And so on, and so on. That is Quality Assurance – monitoring and modifying the development process so that problems are prevented before they happen.

The problem with confusing them

The biggest mistake organisations make here I think is that they put to much emphasis on Quality Control, and not nearly enough (if, indeed, any at all) on Quality Assurance. This causes us to continually stay in pure reactive mode. This is often a symptom of a company that is entirely deadline focused. If the deadline is the most important thing, then everything is rushed to the finish line, and the emphasis on Quality Control (ie, testing) is large. Developers know that they have a huge team of testers waiting to test their code, so they often reduce or drop altogether their own developer testing (unit testing, etc), which leads to more bugs, and more time wasted in the testing-bug fixing phase. When this happens, more effort and attention needs to be put on the QC end of the spectrum, leaving even less time for proper Quality Assurance. And so the cycle continues…

Quality Control and Quality Assurance are both important – but what is more important is to have a balance between them. Too much focus on QC might get your software release out tomorrow, but won’t help you build a quality process for the future.

Work Planning and Productivity

A friend of mine recently asked me to tell her some of the things that I do to stay organised at work. There are countless productivity blogs and sites out there on the web I could have referred her to, but I thought it would be an interesting exercise to sit down and think about what methods I actually use. Here is what I came up with. It seems to be very heavily influenced by David Allen’s Getting Things Done, Inbox Zero, and a bit of common sense thrown in.

Email Zero

The first and ultimate tool of staying sane is keeping at Inbox Zero. This, I think, is one of the super weapons of office productivity. There are heaps of tricks and methods for staying at Inbox Zero, but the main premise is simple: at the end of each day, get your inbox empty. That means no unread emails, no read emails flagged for follow up, nothing. Read everything, put any new actions on your actions list (see below), store information mails in an appropriate folder, and then either trash or file the rest – how you like.

Your inbox is just that – an INbox. It’s where new stuff comes in and sits until you have a chance to deal with it. It’s not a task list, and it is most certainly not a storage system. As soon as it becomes both, both new messages and your to-dos get buried in the mass of junk email.

If your inbox has 2,358 emails in it, and 781 of them are unread – then it’s time to clean house. I would just throw everything older than a week into a folder and forget about it. You’re not going to read it anyway, right? Then process the remaining emails, sorting out actions and information, then sit back and admire your new, clean, empty inbox. You’ll be surprised how refreshing it is to stare at an empty inbox pane in outlook.

The 2 minute rule

After Inbox Zero, this rule is golden, and it is really easy. In fact, if there is just one thing you take from all of this, it should be the 2 minute rule. It’s simple – if the task you’re looking at right now will take less than 2 minutes to do, then do it now. Don’t put it down to do later. Do it now, and then it is done – and you don’t have to waste energy and time picking the issue up again, thinking about it, and deferring it again. This is especially important when cleaning out your inbox.

Know the next action

For each of your projects or responsibilities, there is a next action, and it is sitting on someone’s desk. You need to know, for each project/responsibility etc, what that action is, and on who’s desk it is currently sitting. Bonus points if you know if they are actually actioning it – but if it is important and/or urgent, then you should really find that out, and even better if you can commit them to a deadline. (You should put the deadline in your daily trigger list… see below)

Urgent and Important

This brings me to the next important thing: when you are deciding which task or thing to work on next, you need to know the difference between what is urgent and what is important. Things that are urgent are not always important, but they win out in reality nearly 99% of the time. If the urgent thing sitting on your desk is not really important, isn’t it worth considering spending time on that important thing so you know it gets done?

Lists Keep good lists

The trick with lists is having just enough to have their purpose be uniquely clear and useful, but not too many that you get overwhelmed and stop using them. I keep four basic kinds of lists:

• Action list. If you’ve got a thing you’ve gotta do, it’s an action, and it goes on the list and stays there until it’s done. You can organise/sort the list however you want, or you can even have sub-lists for different kinds of list items. The important things are:
  • Actions are things you do. Try not to add an action to “think about what the next action is”. If you need to think a bit to work out what the next action is, do that now, then add the action to the list.
  • Add all actions that you have to do to the list when you realise that you have to do something – then a) you don’t forget, and b) you aren’t relying on the grey matter to remember.
  • Don’t add any actions that you can’t actually action yet. That is, if this action only becomes something you can do after a certain time, then put it on a trigger list (see below)
• Project list. This is (hopefully) a relatively short list containing all the projects that you are responsible for. Important here is the definition of “project” – it doesn’t mean only big, long-term projects or processes that you have been appointed “Project Manager” for – it is any thing that requires more than one action to solve. For example, “Implement new development branching strategy” is a project, and so is “update release process documentation”.
• Trigger list. When stuff needs to happen on or after a certain day, don’t add it to your action list until it can be done (doing so mixes actions schedules, and unless your action list has 10 or fewer items, it gets unmanageable). I have a 0 minute calendar item at 8am every day of the week, and in there I make a list of the things that either have to happen that day, or are first available to happen. For example, I might add “check that the QA results arrived” or “write email to Metrics team with update on week 1 results”. Check the list as part of your daily planning.
• Maybe/someday list. Whenever something pops into my head and I think “that would be great to do/think more about… one day”, I put it on the Maybe/someday list. Every so often I browse through the list, and either remove stuff that isn’t relevant anymore, or sometimes move things from the “maybe” pile to the “projects” pile.

Write it down

When something pops into my head, I write it down. I’ll either write it straight on my to-do list, or I’ll send myself an email, so it ends up in my inbox, and will be dealt with the next day (when I empty my inbox). My brain doesn’t allow me to remember everything – so I write it down so I don’t have to.

Do one thing at a time

This one I find particularly challenging personally – but it’s really important. The brain is a single-threaded machine (even Internet Explorer has more threads than our brain), and task-switching has a price – every time you switch tasks, your brain has to reset itself and deal with the new task, new boundaries, as well as pull a heap of relevant background information out of deep storage. It wastes time and energy, and it’s usually not worth it. Do one thing at a time, until you’re either finished with the task or you are blocked, then switch. This goes for email and messenger too (easier said than done when it comes to instant messenger, I realise).

If you are working on something really important, then don’t be afraid to close Outlook, turn off messenger and put your phone on silent. The emails, tweets, facebook updates, instant messages and voicemails will all be still there when you go back online.

Plan your day

Use your calendar reminders, but don’t rely on them. Look at the day ahead of you in the morning. What meetings do you have? What things do you absolutely have to get done today? If you need to prepare for a meeting, it is better to prepare in advance of 5 minutes before the meeting.

Look at the trigger list for the day, and add any items to the actions list. Look through the actions list, and get an idea of which items you will work on today.

Take notes

If you’re in a meeting with someone, whether it be an informal chat or a scheduled meeting, take notes. You will not, can not, remember all the important things out of any meeting unless you write them down during the meeting. I don’t care how good your memory is – if there is more than one important thing you need to take away, you’ll forget one of them. So write it down.

Now comes the really important part. Anyone can take notes in a meeting – but the notes are worthless if you don’t use them. When you’re back at your desk, read through your notes. Any actions that you can do in less than 2 minutes, do them now, and putthe rest on your actions list. Put any future things on a trigger list. Did you just land a new project? Put it on your projects list.

Weekly review

The weekly review is where it all comes together. You need to give yourself time, once a week, to go through all of your stuff, and clean house. Either the end of the week or the start of the week is good, but I try to do it at the end of the week so that I can start afresh on Monday, and not have unresolved stuff floating in my head all through the weekend. It really works – when you have gone through all your shit, and planned the next week so you know there are no surprises waiting for you on Monday, it really helps you “switch off” from work over the weekend and enjoy your private time.

Start with your next week’s appointements. Any meetings you need to prepare for? Any deadlines approaching that you need to think about? How will it effect what you choose to do on Monday? Then go through your actions list. Anything important you’ve missed that you should really do before you go home? Any actions not relevant anymore, or that have been done already? Clear them out. Go through any notes you’ve taken in the past week at meetings or whatever, and make sure they’re all cleared of actions and projects. And, most importantly, make sure your inbox is empty!

The Product Vision

As a Product Owner for any product or project, before you can go anywhere with a new product, idea or concept, you need to know exactly what it is that you want to go further with. This is where the product vision comes in. I recently took a 2-day Scrum Product Owner training course from Boris Gloger:

http://www.scrumalliance.org/profiles/30-boris-gloger

from the Scrum Alliance, and one of the things he showed us was creative ways to really define your product vision.

Why is the vision important?

The product vision itself is the goal, the inspiration and the motivation for your team. What are we trying to do? Why are we doing it? Who will use it, and what will it mean to them? A good vision will imbue your team with passion, motivation and direction for the team. In addition to that, the act of defining your product vision forces you to define clearly, for yourself as well, exactly what it is you’re trying to do.

A great article is here

http://www.scrumalliance.org/articles/115-the-product-vision

from the Scrum Alliance website.

Creating the vision – some techniques

Free-writing

Take a pen and a blank piece of paper. Take a second to think about your product, and then write, without stopping, for 5 full minutes. Don’t correct your writing, don’t read over what you’ve written, don’t edit yourself, and most importantly, don’t stop, even to take a quick pause – just write. It’s important that you let yourself write whatever it is that is in your head, but try not to stray too far off the topic of your product. After a minute or two something interesting will happen… you will start to think new thoughts about your product. You may even start to challenge it… this is good!

After 5 minutes, stop writing, and take 3 minutes to read back through what you have written. Underline what you think are the most important bits. Now, repeat the process – 5 minutes writing, and 3 minutes reviewing.

Now, re-write everything that you have underlined in one sentence. Writing it in one sentence forces you to make sure you understand the complete scope of your product well enough to be able to write it succinctly in one sentence.

Free-talking

Find a friend or colleague, and go for a 15 minute walk. It’s important to get out of the office, in the fresh air, and to move yourself a bit. While you’re walking, explain the product to your friend. The act of explaining it to your friend will again force you to think about the product and verbalise it in a way that you wouldn’t normally, and in this way you are forced to think about the problem in a way that you might not otherwise. It is an extremely useful technique – if you can explain the product to a friend or colleague in such a way that gets them excited, then you have the facts ready to write a sentence that describes it also.

It is so important that the Product Vision is clear and inspirational for everyone on your team. What other good methods are there for defining a product vision?

The localisation magic trifecta

When you start inserting new and exotic languages into your application, the first and most obvious kinds of errors you see, I think, will fall into one of two categories:

1. Layout problems due to text width, height or length
2. Functional problems caused by character encoding

The toughest thing about inserting new languages is that each language is… well, a different language, each with their own quintessential idiosyncacies and challenges. You can insert 50 languages, and then see an error or problem that will throw you on the 51st.

There’s not much that can change that, but I have just discovered a trick to make sure you get 90% of the issues out of the way early in your localisation process.

It’s quite simple: you want to see and correct as many different kinds of errors as early as possible, so you can introduce a bit of reliability and predictability into the process thereafter – so you need to pick the right languages in your first localisation round. The real trick is picking not only the languages that typically cause the most problems, but those that represent the “extremes” of the common issues that you have identified.

This is my magic trifecta:

• Thai
• Finnish
• Chinese Traditional

Why?

Thai is the “tallest” language, which means it takes up the most vertical space. Thai has 5 different vertical positions, whereas most languages (such as English) use only three.

Finnish is the “longest” language, in terms of translation length. If you translate one string into 50 languages, it is almost guaranteed that the Finnish translation will be the longest.

Chinese Traditional is one of the most complicated languages from a character encoding point of view, and it also introduces text size problems, which will force you to come up with a way of dynamically re-sizing the text based on language, instead of relying on one style to handle it for all languages. (Chinese characters are quite complex, and at a given font size that would be readable in English, say 10px, Chinese is nearly unreadable, particularly in bold format.)

When you are looking at the list of planned languages and working out the priorities, remember that yes, the business priorities are important, but if you can get these three in first, you will set the application up to make it as easy as possible for future development rounds.

Learning about Scrum

I have always been a waterfall kind of guy. I was trained in the way of the waterfall back in by university days. (It partly goes to show how irrelevant the bulk of university content is: I started my Computer Science degree only 10 years ago, and the only remotely agile methodology that was taught was eXtreme Programming, and that was only a 4th year elective… but that’s another issue.) Since then it has just so happened that the companies and projects that I have been involved in have all followed the “traditional” Software Development Lifecycle that I was taught in Uni, and that I am pretty sure has been used since the birth of the computer.

The company I am working for now has opened my mind up to the concepts and possibilities of agile methodologies, and in particular, Scrum. I was naturally a complete skeptic at first, which I hear is quite normal, but since I joined I have been starting to learn more about Scrum so that I can at least build an informed opinion.

Here is the start of what I’ve learned.

How do I define Scrum

Scrum is an agile development approach that empowers the development team to produce potentially shippable functionality periodically over the development lifecycle, instead of the “everything at the end” approach from the waterfall method. It defines a set of processes and roles that work together to provide a framework to allow the development team to identify the right things to work on at the right time, and create a product iteratively in such a way that at any time, there is a potentially shippable product.

Why Agile?

Agile methodologies were introduced as a response to the failures of traditional “waterfall” software project management methodologies. The high cost overruns, schedule overruns and overall project failures of so many software projects led some practitioners to search for a more adaptable and flexible development approach. Agile methods are methods which aim to accept the true reality of software projects: change happens. Requirements change, priorities change, constraints change, people change – and they all change in ways that you can’t expect, predict or budget for. Agile methods aim to be able to absorb these constant project changes in a way that will allow the project not only to continue, but to adapt and respond quickly to the changing project environment.

How does it work?

Scrum splits the development lifecycle into fixed-length development periods, called “sprints”. The core rule of Scrum is that at the end of a development sprint, the team will have produced a piece of potentially shippable functionality. “Potentially shippable” here means that the functionality is complete, tested, and that it works. This is the core principle of Scrum, and it is the reason that a Scrum method is so able to cope with changing requirements.

At the start of a sprint, the development team will sit with the Product owner in a meeting called “Sprint Planning”. In this meeting, the team and Product Owner will decide together which features the team will work on in that sprint. The features (called Stories) come from a Product Backlog, which is a list of all the required features of the product and their relative size/complexity, prioritised by relative business value. The team will basically choose the stories that are the highest priority, which are possible in this sprint (considering external dependencies), and they will choose only as many stories as they can have completed within the one sprint. This list forms the sprint backlog.

After sprint planning, the sprint begins. A sprint can be 2 weeks, 3 weeks or any number really, as long is it is fixed and consistent. During the sprint, the team will work together on each sprint backlog item in priority order. Once an item is completed, it is marked off the list, and the team moves on to the next item on the list.

Each day during the sprint, the team will have a “daily scrum” or “daily standup” meeting. This is a 15 minute timeboxed meeting whose purpose is to cover a) what everyone has achieved the previous day, 2) what everyone is planning to work on today, and 3) what impediments have been identified in the past 24 hours.

At the end of the sprint, the team should have completed all the items on the sprint backlog. The progress of the team over the course of the sprint can be tracked using the task board and the burn-down chart.

At the end of the sprint, there are two key meetings scheduled: 1) Sprint Review, and 2) Sprint Retrospective. The Sprint Review meeting is where the team will demonstrate each completed feature from the sprint backlog. Starting with the first story, the team will demo the completed functionality in a live environment. After each story demonstration, the Product Owner can either “accept” or “reject” the feature as completed to standard, or not. If the feature is rejected, it gets put back on the product backlog to be done again in another sprint.

The sprint retrospective meeting is something like a post project review meeting, where the team will discuss the last sprint from a process and execution point of view, and aim to identify points to improve to make future sprints easier or more productive.

The end of each sprint cycle, if executed correctly, will produce a piece of potentially deliverable code. When the project budget runs out half way through the project, for example, the result is a set of functioning features. Compare this to a traditional waterfall approach: when the budget runs out half way through the project, the result is nothing. This also makes Scrum extremely adaptive: when requirements change during the project, the only potentially affected areas is what is already built. The features that are still in the backlog have not been fully designed, fully specified etc, so you are not opening the project up to the endless rounds of re-work that goes along with continual project change.

So there’s the summary of what I’ve picked up so far. Over the next few weeks I’ll start to dig a bit deeper into each of the different phases of the cycle.