![]() Agile Software Development and Project Management Glossary. Acceptance criteria. These are specific criteria identified by the customer for each functional requirement. The acceptance criteria are written in simple terms and from a perspective of the customer. Sample format is: As a... I want to... so that I can.... Acceptance testing.Acceptance testing is a validation activity conducted to determine whether or not a system satisfies its acceptance criteria.It is the last phase of the software testing process.Agile. A conceptual framework for undertaking software projects.Agile methods are a family of development processes, not a single approach to software development. Windows Xp Sp3 Professional Keygen Generator more. Additional resources: Agile Manifesto. Twelve Principles of Agile. Behavior Driven Development. Behavior driven development (or BDD) is an agile software development technique that encourages collaboration between developers, QA and non- technical or business participants in a software project. ![]()
BDD focuses on obtaining a clear understanding of desired software behavior through discussion with stakeholders. It extends TDD by writing test cases in a natural language that non- programmers can read. To learn more about BDD> , please visit the Wikipedia page for detailed information. Bottleneck. A bottleneck is a sort of congestion in a system that occurs when workload arrives at a given point more quickly than that point can handle it. It is metaphorically derived from the flowing of water through a narrow mouthed bottle where the flow of water is constrained by the size of its neck. Bugs. A software bug is a problem causing a program to crash or produce invalid output. It is caused by insufficient or erroneous logic and can be an error, mistake, defect or fault. Burndown Chart. A burndown chart is a visual tool for measuring and displaying progress. Visually, a burndown chart is simply a line chart representing remaining work over time. Burndown charts are used to measure the progress of an agile project at both a iteration and project level. Daily Standup/Scrum. A Daily Standup is a whole team meeting that happens at the same time every day that usually lasts 1. The meeting is designed to allow the entire team to synchronize with each other and to understand the flow and challenges of the development process. Each team member should provide the following information: what did I do yesterday, what am I planning to do today, and what impediments do I currently have? Done. Also referred to as “Done Done”, this term is used to describe all the various tasks that need to happen before a story is considered potentially releasable. Epic. A very large user story that is eventually broken down into smaller stories. Estimation. The process of agreeing on a size measurement for the stories, as well as the tasks required to implement those stories, in a product backlog. Feature creep. Feature creep occurs when a software becomes complicated and difficult to use as a result of too many features. Kanban. Kanban, pronounced /ˈkɑnˈbɑn/, is a method for developing products with an emphasis on just- in- time delivery and the optimization of flow of work on the team. It emphasizes that developers pull work from a queue, and the process, from definition of a task to its delivery to the customer, is displayed for participants to see. Lean. Lean software development is a translation of Lean manufacturing and Lean IT principles and practices to the software development domain. Adapted from the Toyota Production System and is a set of techniques and principles for delivering more values with the same or less resources by eliminating waste across organizations and business processes. Pair Programming. Pair programming is an agile software development technique in which two programmers work together at one workstation. One types in code while the other reviews each line of code as it is typed in. The person typing is called the driver. The person reviewing the code is called the observer (or navigator). The two programmers switch roles frequently. Planning Poker. Also called Scrum poker, is a consensus- based technique for estimating, mostly used to estimate effort or relative size of tasks in software development. Product Backlog. Acts as a repository for requirements targeted for release at some point. These are typically high level requirements with high level estimates provided by the product stakeholders. The requirements are listed on the backlog in priority order and maintained by the product owner. Product Owner. The Product Owner represents the voice of the customer and is accountable for ensuring that the Team delivers value to the business. The Product Owner writes customer- centric items (typically user stories), prioritizes them, and adds them to the product backlog. Scrum teams should have one Product Owner. Retrospective. A team meeting that happens at the end of every development iteration to review lessons learned and to discuss how the team can be more efficient in the future. It is based on the principles of applying the learning from the previous sprint to the upcoming sprint.Scrum. Scrum is a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value. . When estimating the relative size of user stories in agile software development the members of the team are supposed to estimate the size of a user story as being 1. What is Scrum? Scrum is another Agile Development framework and has several key features that are shown the Figure given below and explained in detail. It is based on the adaptive and iterative methodology of software development. Scrumban. Scrumban is a mix between Scrum and Kanban, which supposedly contains the best features of both methods. Scrum Master. Scrum is accountable for removing impediments to the ability of the team to deliver the sprint goal/deliverables. The Scrum. Master is not the team leader but acts as a buffer between the team and any distracting influences. The Scrum. Master ensures that the Scrum process is used as intended. . The Scrum. Master is the enforcer of rules. A key part of the Scrum. Master’s role is to protect the team and keep them focused on the tasks at hand. The role has also been referred to as servant- leader to reinforce these dual perspectives. Spike. A short, time- boxed piece of research, usually technical, on a single story that is intended to provide just enough information that the team can estimate the size of the story. Sprint / Iteration. A fixed duration period of time where user stories are chosen to work on. The term Sprint comes from the Scrum methodology and is analogous to the term Iteration. A sprint is defined as a 2- 4 week increment of software development activities that delivers working software and the end of the increment. External influences are not allowed to change the requirements of the stories being worked on. Sprint Backlog. At the beginning of each sprint, the team has sprint planning with an end result being a backlog of work that the team anticipates completing at the end of the sprint. These are the items that the team will deliver against throughout the duration of the sprint. Sprint Planning. Is a pre- sprint planning meeting attended by the core agile team. During the meeting the Product Owner describes the highest priority features to the team as described on the product backlog. The team then agrees on the number of features they can accomplish in the sprint and plans out the tasks required to achieve delivery of those features. The planning group works the features into User Stories and assigns Acceptance criteria to each story. Sprint Review. Each Sprint is followed by a Sprint review. During this review the software developed in the previous Sprint is reviewed and if necessary new backlog items are added. Story Points. Unit of estimation measuring complexity and size. Task. A user story can be broken down in to one or more tasks. Tasks are estimated daily in hours (or story points) remaining by the developer working on them. Taskboard / Storyboard. A wall chart with cards and sticky notes that represents all the work for in a given sprint. The notes are moved across the board to show progress. Team. The Team is responsible for delivering the product. A Team is typically made up of 5–9 people with cross- functional skills who do the actual work (analyse, design, develop, test, technical communication, document, etc.). It is recommended that the Team be self- organizing and self- led, but often work with some form of project or team management. Test Driven Development. An Introduction to Planning Poker. Planning Poker is an agile estimating technique which has become very popular in the last few years. It is based on an estimation technique known as Wideband Delphi which was created by the RAND Corporation either in the 1. The technique was refined by James Grenning in 2. It was made much more popular when it was included in Mike Cohn’s book “Agile Estimating and Planning.” Although the basics of the technique have been around for many years the refinements by Grenning made it usable by agile teams and they have taken full advantage. Planning Poker is extremely simple to play while also being accurate enough to use for agile planning. The basic rules are as follows: Each participant gets a deck of estimation cards representing a sequence of numbers. The most popular sequences involve doubling each card (0, ½, 1, 2, 4, 8, 1. Fibonacci sequence (1, 2, 3, 5, 8, 1. The Fibonacci sequence is generally more popular. The moderator presents one user story at a time to the team. The Product Owner (or equivalent role) answers any questions the team might have about the story. Each participant privately selects a card representing his or her estimate of the “size” for the user story. Usually size represents a value taking into account time, risk, complexity and any other relevant factors. When everybody is ready with an estimate, all cards are presented simultaneously. If there is consensus on a particular number then the size is recorded and the team moves to the next story. In the (very likely) event that the estimates differ, the high and low estimators defend their estimates to the rest of the team. The group briefly debates the arguments A new round of estimation is made (steps 4 and 5 above). Continue until consensus has been reached and the moderator records the estimate. Repeat for all stories. People who promote the use of Planning Poker understand some of the main reasons why it is successful. People like Mike Cohn have been very instrumental in pushing planning poker and even created www. There are very good reasons why most agile trainers and coaches (myself included) promote its use. My personal top 3 reasons planning poker is great are (all of these assume the team is using planning poker appropriately): Fosters collaboration by engaging entire team Creates consensus estimate rather than having a single person driving the estimate Exposes issues early through discussion of each user story. All of those are great reasons to use planning poker, but there are also some ways to help make it work even better. The three items listed above are all very obvious if you watch successful teams using planning poker. But there are small things most people miss which can be done to improve the process. Knowing of those things allows successful coaches to help teams get even better. The beauty of it is you don’t have to be a coach, just someone the team trusts, to help the team get better. So what are these nuggets of wisdom? Those who actually could do the work are the ones that vote. Too often agile teams have everyone vote even if they have no idea about the work involved in the story. Managers don’t vote. Managers are usually incented to have the work take less time, so they often skew the vote too low. However, managers have more experience than the average team member, so I usually give them veto power over the team consensus in one specific circumstance – they can ask the team if they have considered something which may INCREASE the size. They are never allowed to try to get the team to decrease the size. Their opinion carries too much weight and acts as an anchor to the size, dragging it down in direct propoportion to how vigorously they defend their position. When there is a tie in the voting between two sizes which are consecutive, just pick the larger size and move on. Remember, consecutive sizes might be 5 and 8 if you are using the Fibonacci sequence for sizing (1, 2, 3, 5, 8, 1. No one should complain about using the higher number and an equal split usually takes a long time to resolve. It also usually resolves to the higher number, at least in my experience, so let’s use those facts to our advantage and move on. Stop implementation discussions before they go too deep. Teams commonly drive down to the technical details when they are discussing a user story. This is fine to a certain extent, but it should be severely limited. No more than a one minute discussion. The people doing the sizing should determine in their mind the simplest possible solution and pick a size based on that scenario. It seems like more discussion will make the size more accurate, but in reality this just isn’t true. The scale is not very granular so there is a distinct lack of precision. This is done partially to encourage teams to just make their best guess and move on. Use an “I need a break” card. Too often teams will be working hard playing planning poker and not realize some people on the team need a break. Having the “I need a break” card allows someone to draw everyone’s attention to this. Use a timer of some sort to limit discussion. This is self- explanatory. I usually like to limit discussions to no more than one minute. If consensus cannot be reached by the end of the third round of voting pick the largest size and move on. After two rounds of discussion further discussion usually does not yield great results for the time invested. By choosing the largest size the team has a chance to improve upon it, but they will not be in any danger of not having enough time. Not having enough time is a major problem the team is trying to avoid, so this particular short cut should not cause major issues. Have the person creating the user stories meet with QA and Development leads prior to playing planning poker to make sure the user stories have answers to the most obvious questions the team will ask. This allows the team to focus on the size, not spend time gathering information. Remember the baseline. Whatever the team picks as a baseline needs to be consistent from iteration to iteration. If an ideal day is a size 1 then all iterations need to use that reference point. If a particular user story is a size 1 or a size 3 then that needs to remain consistent across iterations. It can sometimes be helpful after a few stories have been sized to bring up the baseline and ask the team if they agree the sizes are truly relative to the baseline. Failure to do this could lead to what I’ll call “size creep” over time. In other words the team slowly changes their baseline mentally to be either larger or smaller than it truly is. This usually shows up as the team not being able to meet their commitment for several iterations even though everything looks more or less the same. Have fun! Playing planning poker should be a fun, collaborative exercise. Too many teams try to grind it out for an hour or two and forget to enjoy their work. There are many ways fun can be injected into the process. One I particularly like is to play real poker with the sizes. Every sized story counts as a poker card and every five stories makes a poker hand. Prior to starting everyone tries to pick which hand will be the best poker hand (i. This encourages them to look at the user stories ahead of time so they can try to make a good guess about which set of 5 will make a straight or 4 of a kind. Winners can even get a small prize. Give Planning Poker along with these tips a try and see if they help your team.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. Archives
October 2017
Categories |