Principles behind the Agile Manifesto

We follow these principles:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

and the contents. Selecting from the highest priority Product Backlog. The Product Owner formulates a plan for doing so that includes a Product Backlog. The tasks that compose this plan are placed in a Sprint . Sprint planning meetings cannot last longer than eight hours²that is. the Product Owner tells the Team what is desired. priorities. During the second four hours of the Sprint planning meeting. when turned into functionality. where the Product Owner and Team get together to collaborate about what will be done for the next Sprint. Each Sprint is an iteration of 30 consecutive calendar days. but it will become clearer as the project moves forward. The Product Backlog is a list of functional and nonfunctional requirements that. and intentions of the Product Backlog. and grouping of the Product Backlog into releases usually changes the moment the project starts²as should be expected. Each Sprint is initiated with a Sprint planning meeting. Scrum Flow A Scrum project starts with a vision of the system to be developed. they are time-boxed to avoid too much hand-wringing about what is possible. The vision might be vague at first. The best architectures. The Team questions him or her about the content. At regular intervals. and the Team tells the Product Owner how much of what is desired it believes it can turn into functionality over the next Sprint. The first four hours are spent with the Product Owner presenting the highest priority Product Backlog to the Team. Simplicity--the art of maximizing the amount of work not done--is essential. then tunes and adjusts its behavior accordingly. requirements. The goal is to get to work. the Team plans out the Sprint. The Team commits to the Product Owner that it will do its best. Because the Team is responsible for managing its own work. When the Team knows enough.Continuous attention to technical excellence and good design enhances agility. Changes in the Product Backlog reflect changing business requirements and how quickly or slowly the Team can transform Product Backlog into functionality. The Sprint planning meeting has two parts. The prioritized Product Backlog is a starting point. and designs emerge from self-organizing teams. the Team selects as much Product Backlog as it believes it can turn into a completed increment of potentially shippable product functionality by the end of the Sprint. purpose. perhaps stated in market terms rather than system terms. The Product Backlog is prioritized so that the items most likely to generate value are top priority and is divided into proposed releases. the team reflects on how to become more effective. will deliver this vision. All work is done in Sprints. it needs a tentative plan to start the Sprint. not to think about working. but before the first four hours elapses. The Product Owner is responsible to those funding the project for delivering the vision in a manner that maximizes their ROI. meaning.

Who do you think would develop a better system: five software developers and with their own tools working together in a single room or five low-skilled hamburger flippers with a well-defined process. At the Daily Scrum. The Agile Values The important thing to understand about the four value statements is that while you should value the concepts on the right hand side you should value the things on the left hand side (presented in red) even more. its development process to make it more effective and enjoyable for the next Sprint. project managers. At this three-hour. Together. within the Scrum process framework and practices. At the start of the second fourhour period of the Sprint planning meeting. the tasks in the Sprint Backlog emerge as the Sprint evolves. modelers. the Daily Scrum. wouldn t yours? The point is that the most important factors that you need to consider are the people and how they work together because if you don t get that right the best tools . not alternatives. A good way to think about the manifesto is that it defines preferences. the most sophisticated tools available. a Sprint review meeting is held.Backlog. encouraging a focus on certain areas but not eliminating others. After the Sprint review and prior to the next Sprint planning meeting. and the clock is ticking toward the 30day Sprint time-box. testers. time-boxed meeting. the Scrum Master encourages the Team to revise. the team gets together for a 15-minute meeting called a Daily Scrum. At the end of the Sprint. and the Sprint retrospective constitute the empirical inspection and adaptation practices of Scrum. the Sprint review. and the best offices money could buy? If the project was reasonably complex my money would be on the software developers. Individuals and interactions over processes and tools. and your customers. the Sprint planning meeting. Teams of people build software systems. the Scrum Master holds a Sprint retrospective meeting with the Team. the Sprint has started. each Team member answers three questions: What have you done on this project since the last Daily Scrum meeting? What do you plan on doing on this project between now and the next Daily Scrum meeting? What impediments stand in the way of you meeting your commitments to this Sprint and this project? The purpose of the meeting is to synchronize the work of all Team members daily and to schedule any meetings that the Team needs to forward its progress. This is a four-hour. Every day. This informal meeting at which the functionality is presented is intended to bring people together and help them collaboratively determined what the Team should do next. and to do that they need to work together effectively including but not limited to programmers. The values of the Agile Manifesto are: 1. time-boxed meeting at which the Team presents what was developed during the Sprint to the Product Owner and any other stakeholders who want to attend.

but a contract isn t a substitute for communication. are interchangeable. giving your users what they prefer? Furthermore. doesn t it make more sense to work in such a manner that you produce software quickly and often. or men and months. If that is the case. it s just that they re not as important as working together effectively. Only your customer can tell you what they want. this can be difficult for management to accept because they often want to believe that people and time. having an understanding of everyone s rights and responsibilities may form the foundation of that contract. Yes. but that s the reality of the job. Having a contract with your customers is important. written properly it is a valuable guide for people s understanding of how and why a system is built and how to work with the system. they ll likely change their minds. Working together with your customers is hard. they likely won t get it right the first. a fool with a tool is still a fool. However. Successful developers work closely with their customers. don t you? Documentation has its place. never forget that the primary goal of software development is to create software.and processes won t be of any use. Yes. Yes. As Fred Brooks points out in The Mythical Man Month. I suspect that users will have a significantly easier time understanding any software that you produce than complex technical diagrams describing its internal workings or describing an abstraction of its usage. When you ask a user whether they would want a fifty page document describing what you intend to build or the actual software itself. not documents otherwise it would be called documentation development wouldn t it? 3. and they educate their customers along the way. they invest the effort to discover what their customers need. Remember the old adage. they likely do not have the skills to exactly specify the system. 2. Working software over comprehensive documentation. Customer collaboration over contract negotiation. don t get me wrong. Tools and processes are important. what do you think they ll pick? My guess is that 99 times out of 100 they ll choose working software. .

. It gives you a rational basis for providing meaningful answers to key questions like "When is this feature likely to be done?" and "What is likely to be done by this date?". Technology changes over time. As work progresses on your system your project stakeholder understands of the problem domain and of what you are building changes. Change is a reality of software development. yet insist they follow ISO-9000 compliant processes and treat their staff as replaceable assets. Even worse. Responding to change over following a plan. The business environment changes. There is nothing wrong with having a project plan. Senior management will always claim that its employees are the most important aspect of your organization. You get the idea people say one thing and do another. People change their priorities for a variety of reasons. in fact I would be worried about any project that didn t have one. management often refuses to provide sufficient resources to comply to the processes that they insist project teams follow. yet will rarely adhere to in practice. However. Everyone will readily agree that the creation of software is the fundamental goal of software development. a project plan must be malleable. The interesting thing about these value statements is there are something that almost everyone will instantly agree to. yet insist on spending months producing documentation describing what the software is and how it is going to be built instead of simply rolling up their sleeves and building it. Agile developers do what they say and say what they do.scrumpytool. although not always for the better. http://www. This has to stop now. there must be room to change it as your situation changes otherwise your plan quickly becomes irrelevant.4. a reality that your software process must reflect.com/ Scrumpy is a free Scrum tool specifically designed to help a Product Owner maintain a Backlog of User Stories.

Releases and Sprints so that you can focus on what is current. Helps you to understand and communicate where the Product is in its development lifecycle. Archiving of Products. Helps the Team understand and monitor their Velocity over time. Long Term Product View y y y Shows you the trajectory of the Product i.Scrumpy's feature set has been carefully scoped to compliment your existing Scrum practices Features Essential Day-to-Day Backlog Management y y y y Models your Portfolio of Products. Drag and Drop Story prioritisation and User Story Release and Sprint assignment. Helps you to establish and communicate your resourcing requirements. Gives the Team the information they need to know how much work they are likely to complete in a Sprint. the rate at which work is being added to the Backlog. . Prints your Story Cards for an iteration. Teams and Sprints simply and naturally. the rate at which work is being done and the rate at which the total work outstanding is changing. Teams. Iteration & Release Planning y y y y y Captures and charts Story Points Committed and User Stories Done by Sprint. Highlights active Sprints and incomplete Releases so you can see more clearly what is happening right now. Helps the Team to measure the effect of engineering practice improvements. Releases.e.

Sits well with your existing Scrum practices. setup and use. Low Impact y y y y y y y y y y Simple.g. Maybe it is a good fit for yours too. CSV Story export so that you can migrate your Product Backlog to other applications should you wish. Doesn't stiffle Team communication. Of course the truth is that there is no single tool for all situations.g. Distributed as Freeware. coherent and robust. Task Planning) features. CSV Story import to help get you started quickly. It gives you more than you can get from a Spreadsheet but without trying to take over your world. Provides User Story Done Date confidence levels based on past minimum. Sprint & Release Stories for stakeholders to view on your intranet. The Bottom Line Scrumpy has just the features you really need in a clean. average and maximum Product Velocity. simple and free package so you can get started with managing your backlog right away. focussed. Screenshots Product Views The Product Backlog . 100% Java so you can run it on your preferred platform e. Radiate your Product Backlog. Mac or Linux etc. Isn't crammed with unnecessary (e. Easy to install. Windows.Expectation Management y y y User Story Done Date Forecasts tell you when each Story is likely to be done and when a specific Release is likely to be available. Doesn't create an illusion of greater determinism than can possibly be achieved. Scrumpy is the right tool for mine.

The Product Chart . For any of the red Stories to be done I would have to achieve a Velocity greater than I have ever managed before. if I achieve the Minimum Product Velocity I have ever managed then the dark green Story will be done by the end of the month. Consequently the Done Date field of the outstanding stories is being coloured to indicate the likelyhood that each Story will be completed by the end of the month. In this example the Forecast Date is set to "30-Jun-09". From this view a number of Stories can be selected. The Hide Done checkbox restricts the view to just the outstanding stories. Clicking on a Release. The application is Popup Menu driven with each Tree node having an appropriate menu of actions. as it happens the Scrumpy application itself. If I achieve the Average Product Velocity then the light green stories will be done by this date and the yellow stories if I achieve the Maximum Product Velocity.This is the main Product Backlog view for. Double clicking on a Story or a leaf node in the Tree will edit that entity. dragged and dropped on the table to alter their priority or onto Releases and Sprints in the Tree to assign them to a Release or schedule them as candidates for a Sprint. So. If one selects a number of Stories thier Story Point total is shown in the bottom right corner. The outstanding Stories each have a Forecast date based on the Average Product Velocity from today thus answering the question "When is this story likely to be done?". This Portfolio containing the latest Scrumpy Product Backlog is shipped with the application. This feature helps us to answer the question "What is likely to be done by this date?". Team or Sprint will show you just the Stories for that entity in the Table view.

e. The actual Min. It is showing that the rate at which work is being added i. Team Views The Team Velocity Chart . Average and Max Product Velocity quantities are available on the Velocity Tab. discovered is slowing and that the rate at which I am doing the work is increasing. The cumulative difference between the two is the amount of work Outstanding. Consequently the work Outstanding has peaked and is starting to decline. a fundamental reality of software development.This Chart shows the 'trajectory' of the Product by illustrating the rate at which work is being Added and Done. This chart illustrates clearly how work is discovered as we proceed.

The Stats Tab provides the precise Velocity values. Web Publication The Product Backlog . Capturing and presenting this information against the actual Story Points Done in the Sprint helps the Team to see if they are consistently under or over estimating how much work they can pull from the Product Backlog in an iteration.A Chart showing the Team Velocity against time allowing you to measure the effect of changes in development practices. helping the Team decide how many candidate Stories they can pull into a Sprint and still have a good chance of completing them all. I have only had this feature for the last couple of Sprints hence the limited Committed Story Point data. Active Sprints are highlighted in red. The Committed bar indicates the total Story Points that were committed at the start of the Sprint.

This screenshot shows the Product Backlog User Stories as published from Scrumpy and displayed in Internet Explorer. . In this way the Product Backlog is always visible to any stakeholders that are interested and they can be printed out for face to face meetings.