A manouver in rugby union. 8 players form each team pack down in formation and push each other.

The halfback for the attacking team puts the ball into the side of the scrum and the hooker attempts to push the ball back to the base of the scrum where the halfback or No. 8 can secure it.

If the defending team wins the scrum it is called a tighthead

Though the term’s origins are likely related to rugby, as Foaf points out above, a scrum is also a journalistic slang term used to describe the often frantic swarming of a public or newsworthy figure outside of a formal press conference or speech setting. Reporters will often want or need clarification about a point that was raised during a speech or something similar. They might also need to ask follow-up questions but may not have had time during the speech or press conference itself. The scrum is also frequently the only opportunity a reporter might have to question public figures, as speeches and press conferences aren’t always everyone’s bag – and some people are newsworthy for their artistic, scientific and athletic accomplishments.

The general act of scrumming depends heavily on “access” to the figure being questioned. Many elected officials usually end up partaking in scrums at some point or another in their careers, but other kinds of heads of state (royalty, for instance) are very rarely questioned in such a manner. The amount of authority held by each official is also a factor; in the U.S., a Senator or Congress member may find him or herself in scrums all the time, whereas the President is more likely to field questions from reporters at organized news conferences. This is generally limited to certain geographical locations, however; since scrums are often thought to be security hazards and potential for terrorist activity and are therefore less common in the United States than they are in Canada and other countries. Scrums are commonplace at sporting events in the U.S., when it might be common for reporters to need clips from athletes and coaches afterwards.

The term (though this particular kind of scrum is often referred to as a ‘media scrum’) was derived from the original definition provided in Foaf’s writeup. It refers to the fact that some encounters can involve pushing, shoving, and in some extreme cases, kicking. The exceptional cases generally only occur when a large group of reporters is attempting to question a particularly important or newsworthy individual. Professors and teaching assistants of mine have said that, during their careers as working journalists, they suffered cuts and bruises from partaking in scrums. The ‘media scrum horror story’ is supposedly one of the most common journalistic anecdotes in Canada.

Media scrums of old usually consisted of reporters surrounding the newsworthy individual, shouting out questions, and writing everything down frantically. (You can almost see the hats with the little 'press tags,' can't you?) The advent and popularity of television and radio news has more or less eliminated the need to write quite as frantically, as even many print reporters opt to record things and transcribe them later. Cameras, microphones and tape recorders have contributed to the ‘claustrophobic’ nature of the scrum, as people not only have to attempt to make room for themselves but also for their equipment.

How to Handle Yourself in a Scrum, Part One

As a journalist, you will likely end up on the reporter end of a scrum at least once. There are a few ways to maximize your journalistic output while minimizing awkwardness and pain. Every situation is going to be different but there are enough common elements in most media scrums – regardless of the situation – to make these tricks work most of the time.

  • Find a good angle and stick with it. Remember, if you’re frantically writing things down (and some reporters still do, even if they’re also taping things – this way they can remember what was most important and where it was on the tape), you’ll really need to hear everything Mr./Ms. Public Official is saying. You won’t have to worry about camera angles and audio levels, but you still need to make sure you get everything down correctly. Pick an angle that suits your “recording” medium and hang onto it for dear life. This is probably going to be difficult if your subject is attempting to move while talking. Microphones and tape recorders work well from a downward angle but this can be hard on your arms and might obstruct the view of some TV cameras. Another technique involves ducking underneath the general fray and reaching up with your recording equipment. This was one of the first things I was taught in radio broadcasting class, but I’ve never tried it.
  • If you need to check audio levels, make sure you do so quickly and accurately before you record too much at the wrong volume. It’s important to check constantly but in a way that still makes it look like you’re paying attention to your subject. If you make it obvious that their rant about taxes or the judicial system is boring you to death, they might avoid any of your attempts at questions. They usually get to decide who gets to ask next.
  • Depending on the size of the scrum, you may have a hard time being heard over other reporters (who will all be attempting to shout out their questions at the same time, guaranteed). You technically need to attempt to get the subject’s attention; the most common way to do this is to use their name (by name I mean the appropriate honourific – Mr., Ms., Judge, Senator, and so on – and their last name). Standard scrum protocol indicates that the source will make it clear to whom he or she is listening. If it doesn’t look like he or she is going to listen to you anytime soon, hope that you get some relevant information or that some of your luckier counterparts thought up similar questions.
  • While confidentiality is a key staple of media ethics, scrums usually require reporters from rival publications and organizations to work together in the event of confusion. It’s generally considered okay to ask others about a word you might have missed while transcribing quotes. Quotes should be provided and reported as accurately as possible. It’s not the end of the world to have to ask someone else if they heard what you heard. Scrums are publicly accessible; that is to say that different newspapers and broadcasts may feature the same quote content and sometimes even similar footage (from different angles, of course). If you were to break into another reporter’s office and steal his or her notes from a private sit-down interview with a high-level government official, you’d be breaking every written and unwritten rule there is. If you’re standing next to that same reporter in a scrum, chances are you’re going to be using the same quotes. It’s okay to want to make sure you got wording right.
  • If you’re a student at an even remotely hands-on journalism school, you will likely end up in a scrum at least once before you graduate. Given the nature of your assignment, you might not even know about the scrum until a short time before you actually have to partake in it. This means you might feel a tad underdressed if, say, you get sent to cover a court case or a press conference on short notice. Don’t worry – people will understand. They had to start somewhere too, and seeing you there might bring back memories of their own training days. Some of my friends were even approached by working journalists after scrums and were offered practical networking advice.
  • How to Handle Yourself in a Scrum, Part Two

    Congratulations, honourable noder! You successfully ran for political office/won that big case/won the lottery/pulled a kitten out of a burning tree! Just as what happened starts to sink in, you notice a large group of people with notepads and tape recorders on the horizon. Then you find yourself swarmed. What do you do? What do you do?

    First things first: stay calm. It’s only a scrum.

    The scrum is probably one of the most dreaded parts of any public figure’s day. While it can be easy to predict when they might occur in some areas (reporters are usually ready and waiting after Question Period in Canada, for instance), unforeseen events can bring on a scrum at any given time. Public figures also usually don’t enjoy them because they have very little time to prepare for them; it can be easy to be caught off-guard by a question and not have a polished response ready. While this is done in part to keep rehearsed answers to a minimum, some things said in scrums have been so ‘off the cuff’ that the speakers had to issue formal apologies. I have never actually been scrummed, but I can tell you a few things from a journalistic point of view.

  • Try to answer questions as thoroughly as you can. You probably just want to get out of there and go home, but the more thorough your initial answers are, the fewer follow-up questions you’ll have to answer. You might have places to be, but so do the reporters: they all have deadlines to meet. They probably don’t want to have to be there with their tape recorders in your face any more than you do.
  • This is somewhat biased, but attempt to at least be cordial with the press on a professional level. Sure, you’re going to have problems with them and all the hounding you’re going to experience now that you’re a top-notch public figure. Yes, politicians of all political backgrounds howled when Canadian opposition leader Stephen Harper told a group of walking reporters (who were following him in a scrum) to “Watch out for the wall, as much as I’d like to see some of you guys hit it.” They’re going to be there whenever you do or say something big, which might be an inconvenience – and some journalists have acquired a reasonably bad reputation for not respecting the privacy of public figures – but if you’ve just made a speech or done anything else even remotely public, they’re going to have questions.
  • You’re pressed for time – and so are the reporters – but try to answer as many different questions as you can. If you don’t, the publications and broadcasts that run this story are all going to have to use the same clips. You just might be associated with that one quote for the rest of your career, which can be deadly if you happen to speak before you think (a key scrum problem) and say something you end up regretting later. This brings me to a related point: you aren’t really going to have much time to prepare for scrums and even when you can, you can’t anticipate every question before it comes. You should probably know how to think quickly on your feet; getting caught completely off-guard in a scrum can be damaging to your reputation. Saying the first thing that comes into your mind is probably even worse.
  • Once the scrum itself is over and you’re about to leave, never, ever, EVER assume that all the recording equipment has been turned off. Never. All it takes is one off-hand comment and one tape recorder to turn you into a political hand grenade. Before you know it, you’ll be on CNN arguing about whether or not all Canadians own dogsleds with Tucker Carlson – you don’t really want that, do you?
  • Some final thoughts

    For every politician who loathes scrums, there is probably another who either likes them or pretends to like them for the sake of appearances. Some media scrums are actually organized by the people responsible for the actual appearance, speech, press conference and so on. Some Canadian politicians were even known to wander the halls of the parliament buildings, actively seeking out reporters. Some journalists have argued whether or not scrums are entirely effective anymore, as they seem to have become another way for public figures to do their own PR.

    For the record, I have been in one scrum. It involved several reporters but was otherwise a very calm affair. I got to hold a microphone in Jack Layton's face. I didn't ask anything; I was too dazed. I was also 18. Part of my coatsleeve ended up on TV.

    Node your practical experience.

    Scrum is one of several agile project management methodologies, which is named after the practice in rugby, where a team huddle together in order to beat an opposing team. One of the central ideas of scrum is that a team has to work hard and pull together in the same direction.

    Scrum is a set of interrelated practices and rules that optimise development environments, reduces organisational overhead, and closely synchronise market requirements with iterative prototyes. Based in modern process control theory, Scrum - when it works well - causes the best possible software to be constructed given the available resources, acceptable quality, and required release dates. Useful product functionality is delivered every x days (often 30 or 14) as requirements, architecture, and design emerge, even when using unstable technologies.

    Whereas Scrum deals primarily with process and project management, it is often efficiently combined with other practices, especially test-driven development and extreme programming.

    This article aims to explain some of the main terms in broad terms, and will be followed with further exploration into each of these terms as time permits.

    User Stories

    All technical functional requirements of a piece of software are captured as user stories, which serves as a request and outline of a piece of functionality.

    User stories are formulated as a mini-story which represents a need or requirement from a user (“As an administrator, I want to be able to disable content flagged as offensive by site users, because this is a legal requirement, and because having a ‘clean’ site improves the user experience”). Good user stories are independent of others, negotiable, valuable to the business, small enough to estimate properly, and it has to have success criteria built in.

    Product Backlog

    The product backlog can be seen as the wishlist for the current project, and consists of all the user stories that are currently being considered for implementation.

    The backlog is ordered by priority, and when planning a new sprint, the theory is that the Product Owner would pick user stories from the top of the stack, which means that the most important work is always completed first.

    The Product Owner is responsible for taking the requirements and ideas from the project stakeholders, and keeping the product backlog in order of priority.

    Sprint Planning

    A sprint is a single x-day cycle of development of the project, and the idea is that we end up with a new increment of the website at the end of a sprint. A sprint might contain work which improves current functionality, new functionality, and bug fixes on old functionality.

    Before the sprint planning meeting, the team figure out what their velocity – or the number of story points the team can do per sprint.

    In the Sprint Planning, the development team work with the Product Owner to estimate and plan the upcoming sprint. This is done by taking stories off the top of the product back-log, and re-estimating the number of story points each story takes, based on the work it would take to complete the stories.

    The team considers the complexity of the site as it stands, the complexity of the development and design which is required, and will come up with an estimate for how much time a particular story will take.


    When the whole sprint has been planned full of stories that need to be worked on, the team commits to the sprint, and go off to spend the next 2 weeks delivering the work they have committed to.

    Once the sprint has started, its scope is fixed, and can no longer be changed. This means that other work that comes up while the iteration is in progress, needs to be scheduled into the next iteration.

    Sprint review meeting / Iteration demo

    In a sprint review meeting, we show off the functionality that has been completed over the past sprint to key stakeholders, and will give enough time for people to ask questions, offer comments, and get to grips with the release better.

    After the sprint review meeting, the development team does a retrospective to find out what went particularly well (or badly) during the past sprint, and then they launch into a sprint planning meeting again.

    Scrum team

    The make-up of a scrum-team is complicated enough to warrant a series of separate articles, but in very short, it consists of a Scrum Master, who is responsible for ensuring that Scrum's principles are followed properly, and to remove any impediments that are in the way of the team.

    The scrum team are the people who are actually working on the product on a daily basis; the engineers who are getting the work done.

    The final role in Scrum is the Product Owner - this is a complicated role, as s/he is the person who decides what the team is working on next by keeping the product backlog prioritised.

    Scrum is an agile software project management method, though it could be used with some adaptation to managing projects of other kinds. "Scrum" is not an acronym, it just reflects the coordinated yet messy and noisy progress that a team can make.


    The "relay race" approach to product development ... may conflict with the goals of maximum speed and flexibility. Instead a holistic or "rugby" approach – where the team tries to go the distance as a unit, passing the ball back and forth – may better serve today's competitive requirements.
      - Hirotaka Takeuchi and Ikujiro Nonaka - "The New New Product Development Game" – Harvard Business Review, January 1986.

    Scrum was popularised mainly by Ken Schwaber and Jeff Sutherland in the 1990s, based on earlier Japanese work. In the 2000-and-noughts, it is becoming popular.

    What's the basic idea?

    "A complex system that works is invariably found to have evolved from a simple system that worked."
      Gall's Law

    Scrum attempts to overcome the shortcomings of traditional, waterfall software development:

    • Upfront design does not cope well with change - it assumes falsely that the users know exactly what they want, and hinders new ideas or discoveries about what would be good.
    • Changing business circumstances on software long projects can make the software obsolete before it is deployed.
    • Late integration and testing means that bugs and design errors are much more costly.
    • But if change is allowed, undisciplined change can lead to chaos, poor quality software, and is avoided by software contractors due to disputes over cost and increased effort.
    • "Big bang deployments" where the system has never been used in production on day zero, and is expected to function perfectly for a large user base on day one have a very poor track record.
    All of these issues arise from the sequential gates that software development goes through: first requirements are completed, then all design is done before all coding, all coding is done before it is "thrown over the wall" to the testing team, and so on. I doubt that anyone actually works exactly this way; it is impossible to do it, there is always to-and-fro between the activities.

    Scrum does the following

    Business Guy: "You mean, with Scrum, I don't have to wait 18 months to get software I don't want?"
    Ken: "No, We'll give you software you don't want in 30 days."
      - An anecdote from Ken Schwaber.
    • Deliver software iteratively, in relatively short cycles of a few weeks. These are called "sprints". If the work can't be finished in the sprint, do not extend the length of the sprint, rather hold some of it over for the following sprint.
    • Deliver complete slices of software. Each sprint delivers a small slice of software with all activities complete - from design through to testing. You don't have to wait until the project is complete before getting some benefit from the software development work. If the project is 10% complete, you should be able to get 10% of the benefit from it right now. In practice, it could be more like 80% benefit from 20% of the software, since high-priority items are done first.
    • Cross-functional teams. Rather than a design team that finishes and hands off to coding team, the scrum team includes all people currently working on the project. All activities happen in parallel. In typical software development, this can including coding (of various flavours such as web front end, back end and database), software testing and deployment, business analysis, user experience and interface design. The team is autonomous and in close communication (co-located if at all possible).
    • Manage change: What the software is supposed do, the requirements, is not to be changed during a sprint. However after a sprint, when planning for the next sprint, any action is on the table, from continuing as before to abandoning the project, redesigning, or moving to a live deployment. But the usual action to re-evaluate the work priorities and commit to doing the items that are now highest-priority.
    • Prioritize work: A prioritized backlog of requirements is kept. Requirements do not all have to be specified in detail before any development work can start. Only one sprint's worth of work needs to be fully detailed before the sprint starts. The rest will be less and less detailed they trail off into the distance.
    • Inspect and adapt Communication is good. Visibility is good. Raise and react to problems quickly. Inspect and adapt the process used and the software created after every sprint, and the project goals as well. Inspect and adapt the priorities of remaining work after each sprint. Inspect and adapt the work being done in a daily meeting.

    What scrum is not

    Scrum is not "high ceremony" and rigid. It is an empirical and light-weight methodology, which aims at getting results. It should encourage the software development team to take their own decisions rather than have them dictated to them by the method. Scrum will not make software design decisions for you. And it will not save you from bad design decisions. Scrum is not a process that specifies what to do for success at every step. It is a method for generating process, and sometimes for discarding process when it's more overhead than it's worth.

    Scrum will not solve all of your problems. At best, scrum will just make problems visible through increased communication. What happens after that depends on your organisation. Scrum will not turn idiots into software superstars. It can unleash the talent, if the talent is there in the first place. The daily scrum will at least give everyone a better idea of how much value each person is adding.

    Scrum will not guarantee success. But if it's done well, the increased feedback will let you at least fail fast where you would have failed slowly without it.

    Scrum is possible to do wrong. In fact it's easy to do it badly, if approached without discipline.

    Scrum is not undisciplined. In fact all agile methods are quite strongly disciplined . They all require strict discipline to adhere to practices such as not breaking the build, no code without unit tests, keeping scrums down to 15 minutes, not changing requirements during sprints, listening to sprint feedback, maintaining the burndown chart, etc.

    Scrum doesn't mean that any aspect of the required software can be changed at any time. In fact, this can only be done in sprint planning. The rest of the time, this is not allowed.

    Scrum does not mean that there is no project documentation. Requirements can be consumed by a scrum team, or design documents generated if you insist; it just happens one sprint at a time.

    Scrum is not a software development method, it is a project management method that is suitable to software development, and other exploratory activities. It is compatible with Agile software development methods such as Test-Driven Development and Extreme programming, and can be used alongside them.

    Scrum is not all that complicated. You can learn it in a week. The rest is common sense and feedback.


    The daily scrum

    The daily scrum is a meeting of all people in the team. It is performed standing up, and should last 15 minutes or less. You generally have three things to say at a scrum:

    • What you did yesterday (or since the last scrum)
    • What you aim to do today
    • Impediments: what obstacles stand in your way.

    A scrum is not the team being told what to do for the day, it is conversation between the members of the team, where everyone tells everyone else what they are doing. Scrum is not intended to exhaustively discuss and solve your obstacles, it is intended to raise them so that they can be discussed with the right people afterwards. Anyone can come to the scrum, but only those committed to the project have something to say. There is a standard story about this:

    A chicken and a pig are together when the chicken says, "Let's start a restaurant!".
    The pig thinks it over and says, "What would we call this restaurant?".
    The chicken says, "Ham and Eggs!".
    The pig says, "No thanks, I'd be committed, but you'd only be involved!".

    The "pigs" or participants in the scrum are the team, ScrumMaster and product owner (this last one is debatable). The company CEO is welcome to sit in as a "chicken", but he's not a "pig".

    If there are too many people on the team for the scrum to work effectively, break it up into smaller teams with their own scrums.

    Scrums typically happen at a fixed time, towards the start of the day.

    The sprint

    The sprint is an iteration of the project, a cycle in which software is produced. In each sprint the team will gather requirements, design, build, test and deliver software. The length of a sprint is generally set for a project at somewhere from 1 to 6 weeks.

    How long should your sprint be? If your project is e.g. experimental, involves rapid prototyping and frequent changes, then it could be as low as one week. If your project is large, or involves relatively fixed requirements for a client who knows well in advance what they want, it could be as long as a calendar month. Six weeks is generally (but not always) too long. If the business has a well-defined business cycle of a month, then you may want to synchronise with that.

    What if you can't deliver what you wanted to in the time given? The deadline does not move, the sprint is not extended. Things that did not happen in the current sprint will be carried over to the next sprint.

    All activities should happen each sprint - the software should be shippable at the end of each sprint. It may not be shipped, and "going live" may involve a sprint in itself, but you should not let "integration work" and a backlog of bugs build up.

    Scrum breaks this down the waterfall by insisting on small iterations, but the sprints are not "mini-waterfalls" with distinct phases, rather the work is overlapping. If front-end developers depend on work done by back-end developers, then the back-end developers will be working up to a sprint ahead of them. The closeness of the team should increase collaboration in reduce the costs of inevitable change.

    Sprint Review and Sprint planning

    At the end of the sprint, there is a sprint review which presents what happened and looks back on what went well and badly. At the start of a sprint, sprint planning starts off the next one. In practice these generally happen back to back, since the sprint ends and the next one starts. How long to spend on these? I have typically seen one day for the two, but it depend on how long your sprint is. If you have month-long sprints, you could devote a day or two without too much drag. On a one-week sprint, a lot less than that.



    A member of the scrum team who removes obstacles, ensures that procedures are followed, keeps charts updated, shields the team from external influences and generally keep the team productive however they can. They must know scrum, and are the closest that scrum comes to having a manager role.

    I have seen good and bad ScrumMasters, and in my opinion the good ones have a certain level of forceful personality. They are able to enforce the rules and tell people what needs to happen once in a while. They are the ones who must interrupt and tell people to "talk about it after scrum". But they are also not micro-managers. They need to let people get on with solving problems in a self-organising way.

    e.g. bad practice:

    Mike: Yesterday I was trying to test the TPS reports, but I was having problems connecting to the departmental database. I'm getting an odd error. Today I will continue trying to fix that.
    Pete: Is that like the Transitive trust issue that I had last month?
    Mike: I didn't know you'd come up against that before. I tried establishing a trust relationship, but nothing changed.
    Pete: That won't work unless you apply a patch.
    Mike: Ok, where can I find the patch?
    ... 5 minutes of technical discussion later, everyone else is wishing they were somewhere else and subconsciously forming the opinion that scrums suck.

    Better, the ScrumMaster gives some guidance:

    Mike: Yesterday I was trying to test the TPS reports, but I was having problems connecting to the departmental database. I'm getting an odd error. Today I will continue trying to fix that.
    Pete: Is that like the Transitive trust issue that I had last month?
    Mike: I didn't know you'd come up against that before. I tried establishing a trust relationship, but nothing changed.
    ScrumMaster: Ok guys, you can sit together and sort it out after scrum.
    Mike: all right.
    Best, the team have internalised the basic rules, and the ScrumMaster gives other guidance:
    Mike: Yesterday I was trying to test the TPS reports, but I was having problems connecting to the departmental database. I'm getting an odd error. Today I will continue trying to fix that.
    Pete: Is that like the Transitive trust issue that I had last month?
    Mike: Yes ... but we can talk about it afterwards.
    ScrumMaster: Good. If this is recurring issue, don't forget to put a note about it on the project wiki.

    Product Owner

    This is the person who says "you are making this software for me and I want it like this". They are the contact point for the vague, changing, contradictory and naive set of wants that we call "software requirements". They may not even be a user of the software, but they do represent them. For instance, for point of sale software used by store clerks, they will not be a store clerk but a manager of store clerks. However a sample user can be brought in to discuss and test actual usage. When software is sold or on the internet, the Product Owner may come from a marketing department.

    The product owner establishes the vision - the concept of what the software is, should have some idea about what the return on investment is, takes the lead in populating the product backlog, has the final say in prioritizing it, and decides when a sprint should be released.

    The product owner does not have to attend every scrum, but if they never or seldom attend this is likely to be a symptom of a problem.

    Team Member

    The scrum team is self-organising. In theory, all team members are equals and work together, picking up work as needed. In reality, you all have different skills. In best practice, your skills rub off on each other from close proximity.

    Other artefacts

    Product backlog

    The product backlog is work to do in the entire software project. It does not need to be complete, you only need to be able to find out what to do in the next sprint. The items in it will be sorted by priority, and the high-priority ones will be detailed enough to put them into a sprint backlog. This accords well with reality of software - we will have some things that we know we want know based on what we have, some less-well defined things that we'd like to have later, and some vaguer, far-away wishes.

    Sprint backlog

    The sprint backlog is work to do during the current sprint. It is planned in sprint planning.


    A "burndown" or "burndown chart" is common- this graph tracks progress over the sprint, showing how much work remains to do over time. The rate it which this decreases is the "velocity". If the line, trended outwards, will not hit zero before the end of the sprint, then you have probably over-estimated the amount of work that the team can handle in one sprint, and one or more tasks will have to be removed from the sprint. If you are lucky enough to have it extrapolated to hit zero well before the end of the sprint, then more work can be added.


    There's lots more to say about Scrum, and you can find books and courses on that. As Methodologies go, scrum is quite simple. You can learn it in a week. Beyond that, it relies on the application of common sense, albeit based on some hard-won realisations about the changeable nature of software development. This is its strength.

    Hirotaka Takeuchi and Ikojiro Nonaka - "The New New Product Development game" Harvard Business review, January 1986
    Ken Schwaber, Mike Beedle: Agile Software Development with Scrum, 2002
    Wikipedia: scrum: http://en.wikipedia.org/wiki/Scrum_(development)
    DeGrace and Stahl, "Wicked Problems, Righteous Solutions" 1991

    Sources: Experience, co-workers, notes from Mike Cohn's Certified ScrumMaster course.

    Log in or register to write something here or to contact authors.