Photo (c) Janusz Gorycki

Extreme Programming postulates, that courage is one of the fundamentally important virtues of an agile developer. I would augment this postulate and claim that it is, together with talent, THE most important one.

Why? Simple. Courage lets you overcome any and all obstacles that may stand in a way of developing a fine piece of software.

For example, I have seen a lot of cases where a programmer would shy away from an interesting project, because thay claim that thay lacked knowledge and expertise in the particular area. Or – the subject matter seemed too hard. They felt not „worthy” to try. Let me be a bit controversial and say: lack of knowledge does not matter. The courage to learn new stuff does.

I will let you in on a secret: the „experts” in any given field have usually just read one HOWTO more than you have. And they are maybe 2-3 months more „seasoned” then you are. If they have more experience in a given technology than a couple of months, the technology is probably obsolete already anyway. In this day and age, you are typically able to google the answer to any and all questions within a couple of minutes. And learn the required technology in a couple of hours. Granted – you won’t (yet) be as proficient as the others, who learned this before you. But you will know enough to get started, and then may actually be enough to get things done. And what if google does not know the answer? Ah, that’s when the fun begins! That’s when you know that you found yourself on the edge of the undiscovered, the uncharted territory. Excitement! Drama! Don’t we all want to be first doing the pioneer’s work? You just need the courage to try.

Another typical example: some people are afraid to „break something”. They fear that if they touch some unknown code, it will blow up at them. I say – so what? Let it explode. Let it break. It is fun to watch stuff disintegrate. That’s how you learn how things work. Introduced some new bug because you tweaked the wrong dial? Bummer – but you have learned something in the process. If you are working the agile way (and do read around this site to learn how – ample advice within on what safeguards to put in place and how to control destructive tendencies), the damage will be easily fixable. If worst comes to worst, you can always revert to the previous revision of your code, can’t you?

Last but not least, let me let you in on a secret – as developers, we have an easy job. It amounts to solving relatively simple logical and mathematical problems to get stuff done. There is nothing to it. The puzzles to solve are, for the most part – trivially easy. Also – the bareer for entry is very, very low – the cost of a very potent workstation is much less than a thousand dollars these days, and often times all of your software tools are free. You can actually build a very successful software company out of you parents’ basement, sacrificing nothing more than a chunk of your spare time. What other proffesion can claim that? Compare software development to, say, construction or biotechnology, or pretty much any other technology-related discipline, where you need the whole set of very very costly tools and materials just to get you started. Developing software is definitely not the most complicated and demanding way to make money. Compared to, say – designing a microprocessor, launching satellites, performing heart surgery – we have it really easy. Yet, there exists an aura of „complicatedness” surrounding software development („You know how to program computers? Gosh, you must be so smart”), which I guess is maintained by some geeks types with low self esteem – which unfortunately often backfires at them badly, because they start to believe that what they are doing is oh so difficult, that even they don’t know how to do it any more.

Planning poker – the real epiphany

Last week I established three good reasons to go with Story Points and why they’re so popular. This week I want to talk about one more important aspect of story points and then provide tips on how to get started estimating in Story Points. I find this is a rather big challenge for teams just learning the ropes.

Lets talk
Scrum is a learning framework. It’s been designed specifically with Inspect and Adapt points with a very specific purpose. Because estimating is a cross-functional team activity estimating the backlog is just another opportunity for the team to get together to discuss the task at hand, for the stakeholder or product owner to explain what is expected of the team. This discussion is a great way to build team morale, synchronize expectations and getting everyone singing to the same tune. Because Scrum projects are agile, it’s important that teams engage in discussion to ensure the team stays on the right track. And because the estimation is done in a team setting the estimate is generally more accurate as it represents a cross functional view of the task size, not just the developer view.

A couple weeks ago, I was helping a company understand how to estimate the backlog. This company is new to agile and I was introducing them to Planning Poker and Story Points. Firstly the idea of Planning Poker was some sort of a joke to them. Second getting them to understand Story Points, a seemingly meaningless measurement, seemed to be a non-starter for them.

Ideal hours first
This is where ideal hours came to the rescue. They were far more able to wrap their heads around ideal hours i.e. if you lock the developers and testers in a room with zero interruptions, how long would it take. I figured that once they got their initial stories estimated in ideal hours down, switching to Story points will be easy as they would have established a scale of reference to compare against. This approach worked really well. They’re now into their 3rd Sprint and now that they have an existing scale, whether the number is in ideal hours or story points or dog points for that matter, it really doesn’t matter any more. If you’re new to agile estimating, and you’re having trouble coming to terms with Story Points try this first and then make the switch later.

The real epiphany
Planning poker for them was a real epiphany. What started out as a joke soon turned out to be a really, really rich experience. For the first time in the companies history, there was actual dialog. The biggest benefit came from the discussion that ensued after the first round of cards were played. The two outliers (i.e. the folks that estimated low and high) were asked to explain why the big difference. The dialog and information exchange at that point was extremely valuable. I watched their faces after the first user story was done. It took only 5 minutes. And everyone was in sync. I saw the light bulbs go on in their heads. They have never looked back since.

Planning poker has to be the simplest most effective ceremony ever invented. I highly recommend it. There are also variations of planning poker, check out James Grenning’s blog for more details

ScrumMaster Murphy: Ten problems in the Daily Scrum, and what you can do about them!

“If that team can find a way to revert to Waterfall, it will!” “Any team that can find a way back to Waterfall will find a way back to Waterfall!” These modern corollaries to Murphy’s Law haunt every Scrum transition and manifest themselves in the Daily Scrum. If the ScrumMaster lets it degenerate, the success of entire transition is called into question. 10 Warning signs that something is wrong in your Daily Scrum and what you can do to correct the problem.

The Daily Scrum is simple daily routine to help the team self-organize, focus, and identify and eliminate impediments to progress. As the backbone of the self-organizing team, the Daily Scrum has nearly nothing in common with a classical project meeting. Team members synch up with each other on what is being done and lay the ground work for self organization — which takes place after the Daily Scrum.

What to watch out for

  1. Storytelling, problem solving and gossip. The ScrumMaster must be ready to prompt the team members to answer the right questions and to stay on track.
  2. Reporting to the ScrumMaster. The purpose of the meeting is for the team members to talk to each other. The ScrumMaster keeps his role to a minimum and keeps the focus of the discussion in to the group. If the team falls back to reporting, conversations become bilateral between ScrumMaster and team member, and other team members risk tuning out. The ScrumMaster’s taking notes is a symptom of this behavior. A variety of strategies, such as rotating the facilitator, passing a “microphone” or having the last person to come start the meeting can be used to mitigate this effect.
  3. Accounting for time rather than results and goals. Team Members should focus on goals and not just on how they plan to pass their time.
  4. Invisible (electronic) task boards make it much harder for people to identify and focus on their goal for the day or identify when a team member has not fulfilled his commitment. Ask your team how to solve this problem.
  5. Other stakeholders attending the Daily Scrum. This is not forbidden, but it is an opportunity for them to give to attempt to give unsolicited advice and instructions. The ScrumMaster should pay close attention to the dynamics and prevent inappropriate interference.
  6. Late Arrivals and Unexcused Absences. Arriving late disrupts the Daily Scrum, threatens the time box and increases the cost of the meeting. Information transfer doesn’t happen or has to be repeated. These can be a sign of resistance or rebellion or other deeper problems which need to be addressed. The shared commitment is called into question. If the delinquent team members also refuse to pay their fines, this is a further sign that work on the team identity, commitment, or the value of the Daily Scrum is necessary. The Retrospective is the place to discuss the value of the Daily Scrum and the teams commitment to doing it.
  7. Not raising impediments. In some contexts (e.g. if trust is lacking or in cultures where maintaining face is important), it may be difficult to raise issues in a meeting. People sometimes forget to mention things in the Daily Scrum. In either case a visible impediments list on the task board where team members are expected to post impediments directly, may be helpful to raise and track impediments.
  8. Not handling impediments. This might be a weakness in the ScrumMaster (e.g. conflicting priorities, overwork, or personal preference) or it might be a visibility problem. In either case, it can be demotivating — why report problems if no one will do anything about them? Making impediments visible on the task board can help with this problem.
  9. Not helping each other. “I’m a developer! You can’t expect me to help a tester.” Getting the team to work together as team is a major goal of the ScrumMaster during the first few months of doing Scrum.
  10. Low Energy – People come, they go through the motions and they leave. And no one really cares. If this is more than just a Monday morning phenomena, then it is a problem to be identified in the Retrospective. Personally, I would be inclined to call a retrospective immediately if this problem persisted for more than a few days.

Do you need a coach?

In theory, the Daily Scrum is simple. In practice, it’s hard to do correctly. Without experience, it can be difficult to recognize and react to these problems. Big companies transitioning to Scrum, like Allianz or Yahoo!, cite coaching as a major factor in the success of those transitions. Coaching and training may seem expensive but these investments usually payback quickly and dramatically: a successful Scrum transition typically brings productivity improvements of at least 30%. The ROI of these investments can easily achieve 100% in the first year.

Murphy is lurking in every meeting. The ScrumMaster’s job is to keep him at bay. If the Daily Scrum is working as it should, it is a powerful tool for improving the productivity and cohesion of a team. What used to be an excuse for non-achievement of some goal becomes a call to action to fix the problem. The payout for doing Scrum well in enormous. Get a coach if you need help, but whatever you do, keep Murphy out of the Daily Scrum to unleash the power hidden in your team.

The significance of Story points

Expecting your teams to estimate in Story Points can be quite a leap of faith. When I first introduced the concept of Story Points at my previous company no-one could wrap their heads around the concept. When it comes to estimating, we’re so accustomed to thinking in days or hours that making the leap to some obscure, seemingly illogical measurement is quite the expectation – especially a bunch of engineers.

Getting used to it
Once you start using Story Points, it usually only takes a couple of sprints before teams start to understand the magic in this new practice.

Many companies I talk to, who have adopted Agile, generally practice a modified Scrum/XP process. Many do not estimate in story points and from my point of view, this is a big mistake. In my opinion, Story Points are the fuel for the Agile machine. If you get the Story Point estimation working well, the rest of the Agile/Scrum process is a breeze.

So what makes Story point estimation so important, so good…

Since this topic is near and dear to my heart, I have lots to say. So in an effort to keep this blog post short, I will present only the first 3 most important aspects of story points this week.

1. Universal measurement

It’s the only mechanism that I know of for universally, determining the size of a user story. What I mean by this is that it’s the same measurement for any member on the team. In other words, if you rate a user story as a 5 story pointer; whether a senior developer or a junior developer on the team is implementing it, it’s still a 5 story pointer. The reason is that this is the relative size of this task compared to other tasks estimated by the same team – it has nothing to do with who is implementing it and how long it’s going to take. If on the other hand, you rather choose to estimate in hours or days, it might be a 2 day task for a Senior developer and a 1 week task for a junior developer. Once the team has had some experience with estimating this way, Story Point estimation becomes quite accurate and can be done very quickly in comparison with traditional estimating techniques.

2. Steady state

The real magic in Story Point estimation is when a team reaches what I call their steady state velocity. Generally this happens after 3 –5th sprint. Assuming all your Sprints are of the same duration (which I highly recommend – subject for another blog), then if the team is averaging lets say 40 story points per sprint then that represents their velocity, no ifs ands or buts. What’s great about this is that scheduling future sprints becomes a no brainer. i.e. the Product Owner get’s to fill the tank with, in this example 40 Story Points, nothing more, nothing less. As a result no unrealistic expectations are placed on the team and since the team is generally able to deliver 40 Story Points per sprint (because they’ve done this before already), the team is setup to succeed rather than fail.

3. In the zone

Story point estimating helps teams reach a sustainable pace. And hitting your targets sprint after sprint is an incredibly powerful and wonderful thing. The team feels really good about their abilities and this encourages them to do better. The business starts to believe in the team and this sets the team up in Zone. When you get into the Zone, the team can generally sustain it’s steady state velocity month after month without burning out. And better yet, they get to enjoy doing it.

If you’re not estimating in story points, start now. You won’t look back!

How to Hold the Daily Scrum

Scrum is simple and Scrum is hard. The Daily Scrum is simple daily routine to help the team self-organize, focus, and identify and eliminate impediments to progress. How do you conduct the Daily Scrum and how do you know if the Daily Scrum is achieving its purpose?

When and Where to hold the Daily Scrum

Scrum defines basic rules for holding the Daily Scrum. The Daily Scrum should be held at the same location and the same time every day, ideally in the team space in front of the team’s big visible task board. The task board displays the release and sprint burn down charts and the state of each task in the sprint backlog. Each task is represented on a card and moves through the columns from “waiting” to “in work” to “done”.

Before the meeting starts, each team member should update the state of his tasks and the sprint burn down chart on the task board. These make the current state of the sprint visible for all to see.

The Daily Scrum should be held first thing in the morning, so that team members use it to focus their planning for the day. Practical considerations, e.g.
decentralized teams
working in different time zones, may require a different time or even changing the time from Sprint to Sprint.

Discipline at the Daily Scrum

The meeting lasts a maximum of 15 minutes. All team members are required to attend personally, by phone or by proxy. Since the meeting is so short, it is essential that people arrive on time and be ready to start at the appointed time. The classic penalty for late arrivals is a $1 fine, paid to the ScrumMaster, but other fines are possible. The fine should not directly or indirectly reward bad behavior.

The Daily Scrum is generally a ‘stand-up’ meeting – no sitting, so people are discouraged from settling in and rambling.

Each team member answers in turn the three questions (only). Only one person may talk at once. The ScrumMaster must intervene if people get off track. Any team member may request a meeting with interested parties to discuss issues that arise during the meeting.

How does the Daily Scrum not work?

A Daily Scrum has several important differences from a classical project meeting:

  1. Neither the ScrumMaster nor anybody else assigns tasks.
  2. The team members do not report to the ScrumMaster, they inform and sync up with each other.
  3. The team does not discuss or resolve issues. Team members agree to talk later about subjects of common interest.
  4. Anyone outside of the Scrum Team has to stand out of the way and is not allowed to talk, make faces or otherwise interfere with the meeting.

Solving problems and going beyond the rules

The most fundamental principle of Scrum is ‘Inspect and Adapt.’ If something is working sub-optimally, then ask yourself ‘why?’ and seek ways to improve.

If your Daily Scrums aren’t working, review the rules: are you really doing a Daily Scrum? If not, why not? If you modify the basic rules of Scrum, you risk accommodating dysfunction. The basic rules are surprisingly well thought out and internally consistent. So as a first step, I would ‘do it by the book’ and see if that helps.

If that’s not enough, Seven Tips for the Daily Scrum and Martin Fowler’s collection of patterns for the daily stand up provide ideas and patterns for further improvement.

How do you know if the Daily Scrum is working well?

In my experience, a good Daily Scrum has several characteristics:

  1. The ScrumMaster does not routinely ask the questions. If s/he does, the meeting degenerates into reporting.
  2. The Team Members talk to each other, not to the ScrumMaster, and even challenge each other on what is being said.
  3. The Daily Scrum stays in its time box. If you are disciplined and doing it right, there is no need for it to exceed 15 Minutes. If you have an ‘After-Scrum’ for other topics, it too should be time-boxed to 15 minutes, and should stay in its time box.)
  4. After the Daily Scrum, you know if you need to talk to your fellow team members. You might not know how they will pass their time, but you know what they are trying to accomplish. If it affects you, you should know it.

Teams that self organize develop a daily rhythm: Quiet before the Daily Scrum. A phase of intense conversation follows the Daily Scrum which then settles into silence until lunch time. Another phase of conversation follows the lunch break and dissolves into silence for the rest of the day. This is pulse of a self-organizing team. If you can feel the pulse, the team is healthy and the Daily Scrum is doing its job.


Photo (c) Janusz Gorycki

“How many resources do you need for this project?”. “How much headcount” – or even: “how many headcounts” – “do we need to hire?” If you are working or have been working in any sort of corporate environment, chances are that you have heared sentences like that. If you are a project manager, you are maybe even using them in your daily work. This sort of vocabulary became common in the software industry and people use it without giving any thought to what these words really represent. “Human Resources” is typically the name of your people-management departament.

If you use phrases like that, please stop. Now. Not because it is offensive to the ones you call “resources” (though it is), not because you are vulgarizing the english language (you probably are, but I am not a native English speaker, so I don’t much care. But similarly ugly HR-type phrases made it to my mother tongue unfortunately).

The valid, business-related reason for stopping this sort of language is that reffering to your people as “resources” skews reality and does measurable harm to your projects.

See, people are not “resources”. They are not coal, they are not water, not electricity, not gas. Especially in a creative discipline like software development. People, and especially teams of people behave in a wildly chaotic and non-linear fashion when it comes to reacting to changes in team size and its structure. It is a common knowledge that adding people to a late project makes it even more late. And it is also known that a brilliant developer is orders of magnitude more efficient than an average one. And that a bad developer can do much more harm than good to a project. What is less often mentioned is that a person is not usually able to work in a creative environment with the same efficiency all the time. For all sorts of reasons. Are they in a good mood? Are they motivated? Are they overworked? Or maybe bored out of their minds? This all matters, as well as the family situation, illnesses, stress. Also – do the team members like each other? Sometimes (but not in all cases) it is important for good performance. Then again – some teams work better when there is a tension between team members. You never know beforehand. What you also don’t know, is how many people you need for a project. You learn it throughout the project. But it depends on who were the people you started with in the first place – it is unlikely that two teams working on the same project would end up with the same end-of-project size.

Now, if you start to try to average out all these absolutely crucial factors and only talk about one number – like “required headcount increase (or reduction) for this quarter” – your view of reality is distorted and you don’t really know what will the effects of these increases or reductions be.

So what IS your resource? Basically it all boils down to one thing: the “resource” here is money that is required to pay for people’s work. Now, you can spend the money in all sorts of ways and it is usually not the brightest idea to just simply hire X average guys to work for you. Maybe you should hire just one, but brilliant guy? Or maybe you shouldn’t hire anybody! Maybe simply spend the money giving a raise to your top star (or a top team)? “Growth” is not necessarily always the right answer.

Well, these days unfortunately you are just as likely to contemplate “headcount reductions”. The way this is usually being done in corporate environments is “20% of headcount has to be let go”. Which ones? Sadly, the typical answer from senior management is “it doesn’t matter, just reduce headcount”. Some sort of “performance evaluation” theater is likely to be performed – if only for legal reasons, but at the end of the day – it is pretty random who gets hit by a firing spree. The fallout after such “random acts of management” is usually catastrophic. It is like carpet-bombing a city and hoping that “on average” you will save some money because the bombed houses will no longer use electricity and water.

One of the companies that we work with has recently renamed their “Human Resources” departament to “Talent”. Admittedly, this is just a symbolic gesture that may or may not have practical consequences. But it means a mindset shift in the senior management of this company – after all, what you want is use people’s talent and skills, and not use them as livestock.

My Agile Team: More Code, More Problems

Picture courtesy of sa ku ra on flickr

Welcome to the newest installment of My Agile Team, my team’s ongoing series of misadventures in trying to get better at Agile development. This time around, we’re still playing Whack-A-Mole on the list of bugs we’ve encountered since Go Live. We stomp one out, another pops up.

What I’m going to discuss this time is our approach to trying to fix these critical bugs while maintaining at least a semblance of our Agile nature. It’s hard to do a planning meeting and decide on what to work on when you’ve got new things popping up and old things dragging on. Read on for more on how we’re planning in the midst of firefighting production bugs.

Bugs incoming!

We did a lot of user testing. I mean a lot. The app is a billing system for an insurance company and 4-6 members of the billing team worked overtime for months to go over the system with as fine of a toothed comb as they could muster. And still, when we went live we started having problems we’ve never seen before. Billing in insurance is complicated and it’s not until you have to live with the decisions you made in development interacting with real people and real situations that you start seeing some stuff, there’s just no way around it.

Planning with fire

The question is, how do we plan for this? We’re trying to keep on the Scrum path and plan but as I mentioned last time, our “Top Priority” / Critical list is now 10 items. As soon as we get rid of one of them, another pops up and since it has to do with people’s money our Product Owner labels them critical. What we’ve been doing is using the critical list as our Product Backlog. We’re still not in the habit of estimating the size of the items the way we’d like to, but with most of these things we don’t know what they are until we get into them anyway. So we basically take the list of critical bugs and split them up based on who originally worked in that area and how much bandwidth people have. Giving people items in the area they worked on is really just to help speed up the process since hopefully the person with the knowledge already in their head will get a faster jump on things. Since these are by definition weird bugs though (if they weren’t weird we’d have seen them before) sometimes prior knowledge doesn’t help.

The Red Queen’s Race

The problem of course comes in between planning meetings when new critical things come up. Since to our Product Owner everything that’s critical needs to be fixed now, there’s not much we can do to re-prioritize. Some things are obvious but most stuff just goes on the list to fix as fast as we can. This is what I mean by Whack-A-Mole, we knock them down but there’s always new ones in their place.

The Finish Line?

At this point we’re just hoping the point where we stop finding new critical things comes soon. Our manager took our extremely rough time estimates and told the company that meant we would be done with everything in 2 months so we’re all shooting for that goal. Any comments from me about this will have to come over beer. 🙂

Agile Much?

At this point I realize that this series hasn’t exactly been All Agile, All The Time as much as I wish it were. I’m doing my best to keep our team and these articles informative and focused on Agile but it’s been difficult. I’m trying to make sure reading about our progress (or lack thereof) isn’t as hard as actually living it but I also think it’s valuable to see somebody else’s story, even when it’s a lot of running in place. I really, really hope that we make progress in the coming weeks and I have better things to write about next time. Thank you for reading and if you’ve kept up with this series, thank you even more.

If you have questions for me or suggestions for something you’d like to see me write about our team, I’d love to hear it in the comments below. Thanks again.

Planning – how we really do it in practice

In this article I describe how we do sprint planning at our company with teams of about 10. I take you through a detailed account end-to-end process and cover all the major points.

The importance of planning
Planning the sprint is where it all starts and so it’s really important to get this right. It’s the foundation on which the next two weeks (in our case) worth of work is based, and without it the sprint falls apart. Set the team up for success by investing the time needed to come up with a well thought out plan. Trust me, it’s worth it. (Read more…)

Some assumptions
Now I’d like to preface my detailed account of our sprint planning with two assumptions: 1) You have already prioritized the product backlog and 2) all high priority items are already estimated in story points (at least enough to cover you for the next 2 or 3 Sprints). Prioritizing and sequencing the backlog is best left for another post.

How we really do it
Our sprint planning goes like this:
1) Presentation of backlog items
2) Selecting high priority items for the sprint
3) Selecting bugs and allotting time for refactoring
5) Working out what we can actually accomplish
6) Adjusting the plan
7) Delivering. On time.

During the first part of the meeting we always get the product owner to present the high priority items on the backlog to the team. We include all team members across all functions, i.e. it’s got to be cross functional. The product owner needs to give a detailed description of each user story, the intended user persona, and justification on why we’re doing it. This inevitably leads to healthy discussion which is very important. If you still want to know more about how the meeting works, check out Peterstev’s article here).

There are 3 buckets of work that we always have to juggle during the sprint planning meeting. New features, refactoring, and bugs. We believe in emergent architecture and as a result we always have some refactoring going on – it’s just part of the ongoing evolution of our codebase. Remember only the user stories are estimated in story points and not bugs (See my previous blog post).

Deciding what to do
The first thing we do is schedule the high priority user stories into the sprint. There is always a bit of haggling over how much refactoring and technical debt should be paid down during the sprint. To determine how many user stories we can fit into the sprint we use the average story point velocity (remember, the average velocity should already account for time to fix bugs).

Next we schedule in bug’s we deem necessary to fix during the sprint.

Breaking things down
Once this is all done, the team does the task breakdown and estimates how much time it’s going to take in hours to complete all the work. We then total the task (user story tasks and refactoring tasks) hours and bug hours to determine the Y-Axis point on the burndown chart.

Adjusting the plan
If that number is greater than the capacity we have available, we work with the product owner to drop user stories from the backlog. There’s no sense in having work in the sprint backlog that you know you’re not going to get to. If the team has a good sprint you can always schedule in more work on the fly.

So there’s a little back and forth that must occur in order to set up a realistic sprint plan that you know the team can deliver on. We always have the product owner on hand even during the task breakdown, in case we need clarification on any of the stories.

If this approach is followed, teams will be best setup to succeed and will be able to maintain a sustained throughput sprint after sprint.

Skip the Daily Scrum? No, thank you!

Last week I gave an introductory talk about Scrum to a group of people in Zürich. One participant asked if it would be OK to make the Daily Scrum a Weekly Scrum? My answer: No way!

The Daily Scrum exists to enable self organization. It helps the team focus, communicate and identify impediments. The team members communicate to each other their progress, goals and impediments. The team members identify how they can help each other to reach the shared goal of the sprint.

Each team member answers three questions:

  1. What did you accomplish yesterday?
  2. What is your goal for today?
  3. What is preventing you from accomplishing your goals?

Syncing up at the Daily Scrum

The first two questions allow the team members to sync up. Yesterday they made commitments to each other. Today they review the results together and make new commitments. Team members can recognize when they need to help each other, work with each other, or just need to talk to each other about specific problems. This is basis of self organization. The ScrumMaster may also identify impediments to progress which require his/her attention.

The answer to the first question confirms that each team member has worked on and achieved what s/he planned to do. Unachieved goals can be a sign that the problem is harder than expected or that the team member needs assistance. Unplanned work can be a sign of many different problems which will prevent the team from achieving its goal. Listening to the answer gives the rest of the team an opportunity to confirm whether the claimed goal has really been achieved.

Focus on your goals for the day

The answer to the second question helps each individual focus on the day’s tasks. Other team members can notice when their work is affected and raise the need to discuss a subject in detail. The second question should also identify free capacity if a team member does not have enough work for the day.

Turn excuses into a Call for Action

The third question serves to systematically identify factors which are impeding the team’s progress, so that these issues can be addressed as quickly as possible. If a team member needs help, e.g. from another team member, from the ScrumMaster, or from somewhere else in the company, this is the time to raise the issue. An impediment is transformed into a call to action and is not allowed to become an excuse for not completing work when the deadline arrives.

So to the participant in Zürich: You’re not doing one now, so it’s not killing you. But if you do Scrum without a Daily Scrum, self organization probably won’t work and impediments won’t get recognized or corrected. From my experience, half of the productivity improvement from Scrum derives directly from the close collaboration among the team members enabled by the Daily Scrum.

You might have compelling arguments why a Daily Scrum is not possible. If Scrum is not suitable for your project, that’s OK. But more likely, you are just trying to accommodate a situation which is suboptimal. So before you skip the Daily Scrum, ask yourself, ‘Can I really afford to skip the productivity benefits? Could I justify this to my Stakeholders?’ And ultimately, your self-organizing Team should have the final word.

Why I don’t use standard user story format that much

image Agile requirements are different from the traditional ones and are usually defined as user stories that allow for slicing functionality in the shippable increments. There are recommendations for a standard user story format and the most known one is “As a <type of user>, I want <some goal> so that <some reason>” popularized by Mike Cohn. The trend for recommending the common format is so strong that there is an evolution and there exist even hacks for making it work in the situations when it doesn’t fit naturally.

I used to be in the same camp of standard format proponents, until I noticed that more and more my stories look closer to “Implement list widget support” and further from “As an application designer I want to use a list widget so that…”.


Those who recommend the standardized format strongly find its usefulness in that it makes you think about the actual user persona or sometimes about a very concrete user. In theory it helps you to make less features just for making the features and more features that will actually be wanted and used by somebody. So why don’t I find it that useful anymore? Well, I know all my user types by heart (I think) and for particular categories I may be able even to list very concrete features needed by a very concrete list of people. Then all these wording just takes space and getting rid of it allows me to focus on the actual feature to be done.

You can argue that the format is useful for starters who don’t know their users and their needs that well. Nice theory, but is a bit of an exaggeration as for me. If somebody is not interested in focusing on the end user and figuring out his real needs, no format on Earth can make him be interested. God knows how many times I was reading stories formally written in canonical format yet making no sense whatsoever and ending as useless half-a-features.


There are two situations when I find the standardized format useful:

  • When you communicate stories to somebody who isn’t in daily contact with you. For example, with external stakeholders and possibly a distributed team (though team will anyway need more detail, than just a clever title)
  • When you have similar functionality for different user categories and want to distinguish between them

In all other cases I find the format no more useful, than any other thinking tool such as modeling team behavior with the help of storming model.

Use the standard user story format if you know what you need it for or if you. I am also going to recommend thinking about its usefulness. Just remember that using standard user story format for the sake of “standardness” is senseless.