Posts Tagged ‘Scrum’

So your organization has decided to implement Scrum, but you’re stuck, wondering what to do first. That is understandable. For all of Scrum’s detailed processes, what is the process for starting the process? Let me put it in another way, how does a team prepare for its first sprint? For many Scrum professionals, the answer is a sprint zero, a preliminary sprint exclusively dedicated to preparing for the first sprint. But which activities it includes, how long it lasts, and what it’s called are all debatable points.

This sprint is best spent focusing on the team’s physical environment. This might include setting up computers, creating a team room, optimizing work stations, etc. Others, however, conceive of sprint zero as a chance to prepare the team for its first sprint planning meeting. For those Scrum professionals, that means sprint zero involves adding a few substantial items to the backlog and writing a piece of functioning code — no matter how small it is. If the first sprint kicks off with the sprint planning meeting, a Product Owner will want to have some estimated items in the backlog.

Since spending too much time on gathering requirements can lead to analysis paralysis, this sprint should be as short as possible — only as long as it takes to accomplish a few preparatory goals. Others, however, argue that sprint zero should be the same length as a regular sprint to help teams adjust to a regular work. With that in mind, it’s not surprising that those who argue that sprint zero should be the same length as any other sprint also assert that it could just as easily be called sprint one. According to these Scrum professionals, the basic goals of sprint zero are — design, infrastructure, process improvement, implementation, test, and validation – are the goals of every sprint.

Sprint zero is contentious among Scrum practitioners. Though they might not all agree on its name or how long it should last, sprint zero preserves the principles and processes of the sprints to follow.


The original post is at :

In Scrum, the teams that complete the work assign effort estimates to every user story. Of course, that assumes that a team can reach a consensus for an appropriate estimate. What happens when a story includes too many unknowns to tell just how big it is? Or what if the story’s requirements are known, but its effort is too huge to complete in a single sprint? We call these stories “epics.” While a team should be able to tackle a typical story in four to sixteen hours, an epic is a story that would require twelve or many more to complete. Most Scrum experts suggest that any task requiring twelve or more hours should be decomposed into several smaller tasks. These stories will not only be smaller in scope, but also more narrowly defined. Basically, breaking down epics helps the development team translate its work into chunks that can be accomplished in a single day.

Is there any danger to estimating an epic? Quite simply, the answer is yes. Estimating epics can be harmful because it creates a false sense of certainty for the Product Owner, who begins to believe that the belief that the requirements, tasks, and effort of the epic are known. When a team estimates an epic, that estimation is just that — an estimation — but it seldom remains a best guess. It is often used for forecasting, which, in turn, becomes the basis of a budget. When that happens, that estimate is now an inflexible projection that binds the team to complete an unknown amount of work while respecting an established budget. This strategy is akin to a trip to the supermarket with a fixed amount of money to spend, but no idea what needs to be purchased. It’s safe to assume that anyone in that situation would have plenty of questions. What am I making? What ingredients are in it? If I can’t afford all of the ingredients, which ones are the most important? Basically, this shopper is left in a tough position: He knows he has a meal to prepare and ingredients to buy, but, apart from that, he’s in the dark. The same could be said of the Product Owner who commits to an estimated epic.


The original post is at :

Cowboy coding is a pejorative term used to describe software development where the developers have autonomy over the development process. This includes control of the project’s schedule, algorithms, tools, and coding style.

A cowboy coder can be a lone developer or part of a group of developers with either no external management or management that controls only non-development aspects of the project, such as its nature, scope, and feature set (the “what”, but not the “how”).

Cowboy coding can have positive or negative connotations, depending on one’s opinions on the role of management and formal process in software development; “cowboy coding” is often used as a derogatory term by supporters of software development methodologies, such as Agile. However, the term has been reclaimed to some extent by those practicing within the community.

I have found a very good article so just pasting it over here. I guess this will explain the topic much more in detail.

“This is a frequently asked question. Let me first explain what is Cowboy Coding. Cowboy coding is the absence of a defined method ,i.e. team members do whatever they feel is correct. Cowboy Coding is a term used to describe a software development where the developers have autonomy over the development process. This includes control of the project’s schedule, algorithms, tools, and coding style. So i guess the explanation itself says that these two terms are not equal.

  1. Agile software development re-evaluates plans frequently, emphasizes face-to-face communication, and values the working software over use of documents. However, most Agile teams do follow defined (and often very disciplined and rigorous) processes.
  2. The Project schedule is not a prerogative of the team in Agile. It is the marketing team which takes the call on this important aspect of the project in Agile Software Development.

There are still a few people who say that the Agile Software Development is similar to or equal to the  Cowboy Style Programming because:

  • There is no documentation.
  • There is change anywhere what so ever.
  • There is no method to define the maintenance phase.

Again, I would say that all this is an individual’s perception and an emphasis on definitive processes for everything. Nothing in Agile stops you from saying no documentation or little documentation – they only ask you to value the cost of the documentation – which is a good thing to do. If there is a value and cost-value graph is good, then documentation should be made. Agile is based on building frameworks and teams which accept changes. This is based on a lot of engineering practices like refactoring, unit testing and automated tests [which leads to cohesion and coherence – both desired qualities of a good code] as well as having a good framework for product managers and coders to interact through out the product lifecycle. Rather than working on the principle that changes are caught early in the development lifecycle which are easier to fix, Agile focuses on creating processes and environment where changes at any stage can be responded to readily, i.e. it makes it easy for development team to suggest alternative ways to get quicker to market as well as get feedback quickly. It also enables them to align their code and design from a business standpoint. This along with engineering practices, helps the team to respond quickly to the changes. 

Actually if seen carefully it is not a question of change or no change but the market environment:

  • Can any good product manager give you solid no-change requirements for anything longer than 02 months in current business environment anyways?
  • What is best – to have a slow response to these requirements or rapid responses?
  • If your product is now in the market, probably maintenance will be one area you want maximum attention. Nothing in Agile makes you focus less on maintenance and more on new product development.

Agile is a value stream – whatever brings you value, inspect for that and adapt it. It emphasis the system as a whole with clearly defined roles – something which Cowboy Coding does not unless the only way you can derive success is by having everything entrusted to group of developers – which can very well be the case only during the initial stage of your project.”


The Original post is at :

In Scrum, an impediment is anything that keeps a team from being productive. An impediment can literally be anything, from a team member who is slacking to a freezing team room. But if it’s blocking the team from performing to the best of its abilities, it’s an impediment.

To help maximize efficiency, the role of the ScrumMaster is completely dedicated to resolving impediments. The ScrumMaster works in various capacities, including helping the Product Owner prepare the backlog and ensuring that important Scrum artifacts are visible, but the ScrumMaster’s primary responsibility is to eliminate impediments and facilitate a team’s optimum performance. In this arrangement, it is the team’s responsibility to communicate what impediments are holding them back. This communication occurs each day in the daily Scrum, when team members report on what they’ve accomplished in the past 24 hours, what they plan to accomplish in the next 24 hours, and what impediments obstruct them. Scrum systematizes feedback to ensure that a ScrumMaster always knows exactly what challenges are keeping the team from success and can work to remove them.

It’s also possible for impediments to apply to an organization, particularly in regard to Scrum. Just like a broken keyboard, for instance, would prevent a team member from writing code, an organizational “culture clash” obstructs a smooth Scrum adoption. In scenarios like this, a company needs an advocate inside the company to help management recognize the benefits of Scrum. Basically, such an advocate would be acting like a ScrumMaster, removing barriers before a single Scrum team has been created. Still, even an organizational Scrum advocate does not ensure that Scrum will stick. But, like the ScrumMaster who works closely with a team to eliminate barriers, an internal Scrum advocate helps enact positive change and contributes toward a successful Scrum adoption.


The original post is at  :

In Scrum, the product backlog is the single most important artifact. The product backlog is, in essence, an incredibly detailed analysis document, which outlines every requirement for a system, project, or product. In simpler terms, it could be described as a comprehensive to-do list, expressed in priority order based on the business value each piece of work will generate. Philosophically, the scrum backlog is the engine of the business, it breaks the big-picture story down into manageable increments of work called Product Backlog Items (PBIs).

When the sprint planning meeting occurs, the Scrum team converses with the Product Owner to determine what work they will tackle in the impending iteration. At this time, the Product Owner imports PBIs from the into the sprint backlog.

Now, you may be wondering what a backlog looks like. The answer to that rests on whether a Scrum team uses manual agile or an agile tool to track progress. With manual agile, a team would create a physical manifestation of the backlog, using a dry erase board, Post It notes, or a taskboard. This is ideal for teams that work in closely proximity, whether the same office or room. In this setting, every team member has easy access to the product backlog, the sprint backlog, and the status of its stories, they can simply get up from their desks and walk over to them.

When Scrum teams are not collocated, however, they often require a tool to help them all stay on the same page. There are numerous tools designed to bring geographically distributed teams together using a virtual taskboard. Danube publishes ScrumWorks® Pro, a Scrum management tool that gives users a Web-based task management interface that mimics the look and feel of a physical taskboard. The tool also offers more detailed views of the product and sprint backlogs, organized in adjacent panes and easily modified with drag-and-drop prioritization.

Although it is the team’s responsibility for completing the work, the Product Owner is the only one who can prioritize work in the scrum backlog or, after negotiating with the team, add work to the sprint backlog.




In the Scrum method of agile software development, work is confined to a regular, repeatable work cycle, known as a sprint or iteration. In by-the-book Scrum, a sprint is 30 days long, but many teams prefer shorter sprints, such as one-week, two-week, or three-week sprints. But how long each sprint lasts is something for the team to decide, who must weigh the advantages or disadvantages of a longer or shorter sprint for their specific development environment. The important thing is that a sprint is a consistent duration.

During each sprint, a team creates a shippable product, no matter how basic that product is. Working within the boundaries of such an accelerated timeframe, the team would only be able to build the most essential functionality. However, placing an emphasis on working code motivates the Product Owner to prioritize a release’s most essential features, encourages developers to focus on short-term goals, and gives customers a tangible, empirically based view of progress. Because a release requires many sprints for satisfactory completion, each iteration of work builds on the previous. This is why Scrum is described as “iterative” and “incremental.”

Every sprint begins with the sprint planning meeting, in which the Product Owner and the team discuss which stories will be moved from the product backlog into the sprint backlog. It is the responsibility of the Product Owner to determine what work the team will do, while the team retains the autonomy to decide how the work gets done. Once the team commits to the work, the Product Owner cannot add more work, alter course mid-sprint, or micromanage.

During the sprint, teams check in at the daily Scrum meeting, also called the daily standup. This time-boxed meeting gives teams a chance to update project status, discuss solutions to challenges, and broadcast progress to the Product Owner (who may only observe or answer the team’s questions).

Just as every sprint begins with the sprint planning meeting, the sprint concludes with the sprint review meeting, in which the team presents its work to the Product Owner. During this meeting, the Product Owner determines if the team’s work has met its acceptance criteria. If a single criterion is not met, the work is rejected as incomplete. If it satisfies the established criteria, then the team is awarded the full number of points.

Because certain sprints are hugely successful and others less than ideal, a team also gathers at the end of each sprint to share what worked, what didn’t, and how processes could be improved. This meeting is called the sprint retrospective meeting.


The original post is at :

There are three fundamental roles in the Scrum method of agile software development: the Product Owner, the ScrumMaster, and the Team. The second role I’d like to examine is the ScrumMaster, who serves as a facilitator for both the Product Owner and the team. He or she has no management authority and may never commit to work on behalf of the team.

In Scrum, the ScrumMaster is an arduous role and demands a distinct personality type to succeed. The best ScrumMasters are real team players, who receive as much satisfaction from facilitating others’ success as their own. They must also be comfortable surrendering control to the Product Owner and team. For those two reasons, traditional project managers don’t usually make great ScrumMasters.

So, specifically what does a ScrumMaster do? First and foremost, the ScrumMaster remove any impediments that obstruct a team’s pursuit of its sprint goals. In other words, the ScrumMaster does everything he or she can to facilitate productivity. When a developer’s computer dies, it’s the ScrumMaster’s job to get it back up and running or get another one. If developers are complaining about the high temperature in the team room, the ScrumMaster must find a way to cool it down. It might be easy to summarize a ScrumMaster’s work in a sentence or two, but scenarios he or she could face are truly infinite.

But a ScrumMaster’s work doesn’t solely address the needs of the team, he or she is also responsible for helping the Product Owner maximize productivity. Facilitating productivity for the Product Owner might include helping maintain the backlog and release plan or radiating Scrum artifacts to ensure the Product Owner is informed about the team’s successes.


The original post is at :

There are three fundamental roles in the Scrum method of agile software development: the Product Owner, the ScrumMaster, and the Team. I’ll begin by discussing the Product Owner because it is the most demanding of the roles.

In Scrum, the Product Owner is the one person responsible for a project’s success. The Product Owner leads the development effort by conveying his or her vision to the team, outlining work in the scrum backlog, and prioritizing it based on business value. Of course, he or she must also consider the stakeholders (to make sure their interests are included in the release) and the team (to make sure the release is developed by the deadline and within budget). As such, the Product Owner must be available to the team to answer questions and deliver direction.

But this combination of authority and availability to the development team makes it hard for the Scrum Product Owner not to micro-manage. Scrum values self-organization and as a result, the Product Owner must respect the team’s ability to create its own plan of action. This means that a Product Owner is forbidden to give the team more work in the middle of the sprint. Even if requirements change or a rival organization unveils a new product that renders the team’s work all for naught, the Scrum Product Owner cannot alter the sprint until the next sprint planning meeting.

Furthermore, it is the Product Owner’s responsibility to consider which activities will produce the most business value. This means making tough decisions—that the team might not appreciate—during sprint planning. However, the Product Owner is the one person who must face the music if the project crashes and burns. Therefore, he or she must aggressively determine which features of a product are most important, when they are developed, etc. Just as the development team must produce the negotiated work for the Product Owner, the Product Owner must deliver the product to the customer.




is an iterative incremental process of software development commonly used with agile software development. Despite the fact that “Scrum” is not an acronym, some companies implementing the process have been known to adhere to an all capital letter expression of the word, i.e. SCRUM. This may be due to one of Ken Schwaber’s early papers capitalizing SCRUM in the title.
Although Scrum was intended to be for management of software development projects, it can be used in running software maintenance teams, or as a program management approach.

In 1986, Hirotaka Takeuchi and Ikujiro Nonaka described a new holistic approach which increases speed and flexibility in commercial new product development. They compared this new holistic approach, in which the phases strongly overlap and the whole process is performed by one cross-functional team across the different phases. The case studies come from the automotive, photo machine, computer and printer industries.
In 1991, DeGrace and Stahl, in Wicked Problems, Righteous Solutions referred to this approach as Scrum, a rugby term which was first said by Takeuchi and Nonaka in their article. In the early 1990s, Ken Schwaber used an approach that led to Scrum at his company, Advanced Development Methods. At the same time, Jeff Sutherland developed a similar approach at Easel Corporation and was the first to call it Scrum. In 1995 Sutherland and Schwaber jointly presented a paper describing Scrum at OOPSLA ’95 in Austin, its first public appearance. Schwaber and Sutherland collaborated during the following years to merge the above writings, their experiences, and industry best practices into what is now known as Scrum. In 2001 Schwaber teamed up with Mike Beedle to write up the method in the book “Agile Software Development with SCRUM”.

Scrum is a process skeleton that includes a set of practices and predefined roles. The main roles in Scrum are the ScrumMaster who maintains the processes and works similarly to a project manager, the Product Owner who represents the stakeholders, and the Team which includes the developers.
During each sprint, a 15-30 day period (length decided by the team), the team creates an increment of potentially shippable (usable) software. The set of features that go into each sprint come from the product backlog, which is a prioritized set of high level requirements of work to be done. Which backlog items go into the sprint is determined during the sprint planning meeting. During this meeting the Product Owner informs the team of the items in the product backlog that he wants completed. The team then determines how much of this they can commit to complete during the next sprint. During the sprint, no one is able to change the sprint backlog, which means that the requirements are frozen for a sprint.
Scrum enables the creation of self-organizing teams by encouraging co-location of all team members, and verbal communication across all team members and disciplines that are involved in the project.
A key principle of Scrum is its recognition that during a project the customers can change their minds about what they want and need (often called requirements churn), and that unpredicted challenges cannot be easily addressed in a traditional predictive or planned manner. As such, Scrum adopts an empirical approach – accepting that the problem cannot be fully understood or defined, focusing instead on maximizing the team’s ability to deliver quickly and respond to emerging requirements.One of Scrum’s biggest advantages is that it is very easy to learn and requires little effort to start using.

Several roles are defined in Scrum, these are divided into two groups, pigs and chickens, based on a joke about a pig and a chicken.
A pig and a chicken are walking down a road. The chicken looks at the pig and says, “Hey, why don’t we open a restaurant?” The pig looks back at the chicken and says, “Good idea, what do you want to call it?” The chicken thinks about it and says, “Why don’t we call it ‘Ham and Eggs’?” “I don’t think so,” says the pig, “I’d be committed but you’d only be involved.”
So the pigs are committed to building software regularly and frequently, while everyone else is a chicken: interested in the project but really irrelevant because if it fails they’re not a pig, that is they weren’t the ones that committed to doing it. The needs, desires, ideas and influences of the chicken roles are taken into account, but not in any way letting it affect or distort or get in the way of the actual Scrum project.

“Pig” roles
Pigs are the ones committed to the project and the Scrum process, they are the ones with “their bacon on the line.”

  • Product Owner
    The Product Owner represents the voice of the customer. They ensure that the Scrum Team works with the right things from a business perspective. The Product Owner writes User Stories, prioritizes them, then places them in the Product Backlog.
  • ScrumMaster (or Facilitator)
    Scrum is facilitated by a ScrumMaster, whose primary job is to remove impediments to the ability of the team to deliver the sprint goal. The ScrumMaster is not the leader of the team (as they are self-organizing) but acts as a buffer between the team and any distracting influences. The ScrumMaster ensures that the Scrum process is used as intended. The ScrumMaster is the enforcer of rules.
  • Team
    The team has the responsibility to deliver the product. A small team of 5-9 people with cross-functional skills to do the actual work (designer, developer, tester, etc.).

“Chicken” roles
Chicken roles are not part of the actual Scrum process, but must be taken into account. An important aspect of an Agile approach is the practice of involving users, business and stakeholders into part of the process. It is important for these people to be engaged and provide feedback into the outputs for review and planning of each sprint.

  • Users
    The software is being built for someone!
  • Stakeholders (Customers, Vendors)
    The people that will enable the project and for whom the project will produce the agreed upon benefit(s) which justify it. They are only directly involved in the process at sprint reviews.
  • Managers
    People that will set up the environment for the product development organizations.


  • Product Backlog : It is a high-level document for the entire project. It contains broad descriptions of all required features, wish-list items, etc. It is the “What” that will be built. It is open and editable by anyone. It contains rough estimates, of both business value and development effort. Those estimates help the Product Owner to gauge the timeline and, to a limited extent, priority. The product backlog is property of the Product Owner. Business value is set by the Product Owner. Development effort is set by the Team.
  • Sprint Backlog : It is a greatly detailed document containing information about how the team is going to implement the requirements for the upcoming sprint. Tasks are broken down into hours with no task being more than 16 hours. If a task is greater than 16 hours, it should be broken down further. Tasks on the sprint backlog are never assigned, rather tasks are signed-up for by the team members as they like. The sprint backlog is property of the Team. Estimations are set by the Team.
  • Burn Down : It is a publicly displayed chart showing remaining work in the sprint backlog. Updated every day, it gives a simple view of the sprint progress. It should not be confused with an earned value chart.

Following are some general practices of Scrum:

  • Customers become a part of the development team.
  • Like all other forms of agile software processes, Scrum has frequent intermediate deliveries with working functionality. This enables the customer to get working software earlier and enables the project to change its requirements according to changing needs.
  • Frequent risk and mitigation plans developed by the development team itself. – Risk Mitigation, Monitoring and Management (risk analysis) at every stage and with commitment.
  • Transparency in planning and module development – Let everyone know who is accountable for what and by when.
  • Frequent stakeholder meetings to monitor progress – Balanced (Delivery, Customer, Employee, Process) Dashboard updates – Stakeholders’ update – You have to have Advance Warning Mechanism.
  • No problems are swept under the carpet. No one is penalized for recognizing or describing any unforeseen problem.
  • Workplaces and working hours must be energized. – “Working more hours” does not necessarily mean “producing more output.”

The following terminology is used in Scrum:

    Product Owner :
    The person responsible for maintaining the Product Backlog by representing the interests of the stakeholders.
    ScrumMaster : 
    The person responsible for the Scrum process, making sure it is used correctly and maximizes it benefits.
    Team : 
    A cross-functional group of people responsible for managing itself to develop the product.
    Scrum Team :
    Product Owner, ScrumMaster and Team.
    Sprint Burn Down Chart : 
    Daily progress for a Sprint over the sprint’s length.
    Product Backlog :
    A prioritized list of high level requirements.
    Sprint Backlog : 
    A list of tasks to be completed during the sprint.
    Sprint : 
    A time period (typically between 2 weeks and 1 month) in which development occurs on a set of backlog items that the Team has committed to.
    Sashimi : 
    A slice of the whole equivalent in content to all other slices of the whole. For the Daily Scrum, the slice of sashimi is a report that something is done.

Though Scrum was originally applied to software development only, it can also be successfully used in other industries. Now Scrum is often viewed as an iterative, incremental process for developing any product or managing any work.

Scrum applied to product development
Scrum as applied to product development was first referred to in “The New Product Development Game” (Harvard Business Review 86116:137-146, 1986) and later elaborated in “The Knowledge Creating Company” both by Ikujiro Nonaka and Hirotaka Takeuchi (Oxford University Press, 1995). Today there are records of Scrum used to produce financial products, Internet products, and medical products by ADM.

Scrum as a marketing project management methodology
As marketing is often executed in project-based manner, a lot of generic project management principles apply to marketing. Marketing can be also optimized similar to project management techniques. Scrum approach to marketing is believed to be helpful for overcoming problems experienced by marketing executives. Short and regular meetings are important for small marketing teams, as every member of a team has to know what the others are working on and what direction the whole team is moving in. Scrum in marketing makes it possible to:

  • See possible problems at early stages and allows coping with them quicker and with minimal losses. According to the key principle of Scrum “no problems are swept under the carpet”, every team member is encouraged to describe the difficulties he is experiencing, as this might influence the work of the whole group.
  • Reduce financial risk. With the beginning of every sprint period, the business owner can change any of the marketing project parameters without penalty, including increasing investments to enlarge consumers’ quantity, reducing investments until unknowns are mitigated, or financing other initiatives.
  • Make marketing planning flexible. Short-term marketing plans based on sprints can be much more effective. Marketing managers get an opportunity to switch from one promotion method to another, if the first one proved to be unsuccessful during the sprint period. It also becomes easier to clarify due dates of every small, but important, task to each member of a team.
  • Involve clients in various ways.

There’s also a tendency to execute Scrum in marketing with the help of Enterprise 2.0 technologies and Project management 2.0 tools.


  • Schwaber, Ken (1 February 2004). Agile Project Management with Scrum, Microsoft Press. ISBN 978-0-735-61993-7.
  • Takeuchi, Hirotaka; Nonaka, Ikujiro (January-February 1986). “The New Product Development Game” (PDF). Harvard Business Review,
  • DeGrace, Peter, Stahl, Leslie Hulet (1 October 1990). Wicked problems, righteous solutions, Prentice Hall. ISBN 978-0-135-90126-7.
  • Sutherland, Jeff (October 2004). “Agile Development: Lessons learned from the first Scrum” (PDF).