Agil Ordlista

Agil Ordlista


  1. Acceptance Test
  2. Agile
  3. Agile Business Intelligence
  4. Agile Manifesto
  5. Backlog
  6. Backlog Grooming
  7. Burn Down Chart
  8. Burn up Chart
  9. Daily Scrum or Daily Stand-up Meeting
  10. Decomposition
  11. Definition of Done
  12. Pair Programming
  13. Planning Poker
  14. Product Backlog
  15. Product Owner
  16. Release Plan
  17. Release Planning
  18. Stand-Up Meeting
  19. Story points
  20. Task
  21. Task Board
  22. Technical Debt
  23. Test-Driven Development (TDD)

24. User Story

25. Values
26. Velocity
27. Waterfall
28. Work in Progress (WIP)
29. Demo
30. Epic
31. Extreme Programming (XP)
32. Fibonacci Sequence
33. Impediment
34. Kanban
35. Minimum Viable Product

36. Retrospective
37. Scrum
38. Scrum Board
39. Scrum Master
40. Spike
41. Sprint
42. Sprint Backlog
43. Sprint Planning
44. Sprint Planning Meeting
45. Sprint Review
46. Stakeholder


Acceptance Test

Also: Functional test, customer test

The test is used to define whether a certain feature of the software is functional or not. The pass/fail test can be written in plain English usually by the customer or the product owner. The user clicks and the session are reset and the user is redirected to the homepage. The acceptance test is later programmed by the developer to ensure that it easily works on all iterations of the software. This also helps the developers make sure that the accepted feature of the software was not broken by the newer development. The acceptance test is also known as regression testing, functional test, and customer test. The test is the main feature of the test-driven development (TDD)


The Scrum does not give details of testing methods as testing is not part of Scrum framework. But most Scrum teams test and within the Scrum framework, the product owner is the best person to define acceptance tests for their software.


The idea of acceptance testing is not only limited to software development. The engineering industry also focuses on acceptance testing and is commonly known as black-box testing to them.

Acceptance testing is common in Agile. However, the term is derived from XP. According to, acceptance tests were introduced as functional tests since they were used to find out whether a certain feature of the software works properly or not. Kent Beck, the creator of extreme programming proposed to change the name in April.


Agile is an alternative to the traditional ways of project management. It is commonly used in software development. The methodologies of Agile include Extreme Programming (XP), Scrum, Crystal, Lean, Dynamic Systems Development Method (DSDM), and Feature-Driven Development (FDD). The Agile methodologies are an alternative to the waterfall or the traditional sequential development. The agile methodologies put importance on small teams delivering small increments of working software with great frequency while working in close collaboration with the customer and adapting to changing requirements.


The term “Agile” was first used by a group of Software developers who united at a ski lodge in Snowbird, Utah for a combined purpose of naming and defining the software movement of which they all were considered to be participants. The invitation of the meeting in Snowbird went out to those individuals who were interested in “lightweight” development frameworks. The participants of the meeting jointly agreed that the term did not suit their idea, and thus agreed on the term “Agile”.

Agile Business Intelligence

Agile business intelligence refers to the broad needs it takes to enable flexibility by accelerating the time it takes to deliver the value with BI projects. This includes technology deployment options such as self-service BI, data discovery dashboards, and cloud-based BI. This allows the users to initiate the work with data which is faster and adjustable to the changing needs.

To alter traditional BI project development to fit the needs of the users, many organizations execute formal methodologies that use agile software development techniques and tools to increase their development, testing, and operation. Some important features of the agile approach include ongoing scope; deliver working components, scrum sessions, rapid iterations, evolving requirements, and frequent and detailed testing.

Agile manifesto

Also known as the manifesto for Agile Software Development, the Agile Manifesto is a set of ideas and values that are created by individuals with a similar point of view. The representatives of Extreme Programming, DSDM, Crystal, Scrum, Adaptive Software Development, feature-driven development, pragmatic programming, etc made the Agile Manifesto that feature four important aspects:

•    Communications with the individuals over processes and tools

•    Working software over comprehensive documentation

•    Partnership with the customers over contract negotiation

•    Responding to change over following a plan


The twelve principles of the Agile Manifesto:


1.    Satisfying the customer through rapid and continuous delivery of useful software’s.

2.    The working software is delivered within weeks

3.    The working software is the principal measure of progress

4.    Welcoming the changing requirements

5.    The business people and the developers to work together daily

6.    Having face-to-face conversations which is the best way to convey information

7.    The projects are built around motivated individuals

8.    Constant monitoring to technical excellence and good design

9.    Simplicity

10.    Self-organized teams

11.    Regular revision and adjustments to changes

12.    Maintaining a constant pace for completed work



A backlog is a list of features or tasks maintained by the Agile team which are known to be necessary in order to complete a project or a release. The backlog is the main entry point of all Agile projects and each team working on any project has to create a backlog for each development iteration.

The backlog typically includes features or requirements that are assigned by the development team. The customers or their representative prioritizes the items in the backlog.

Backlog Grooming

1.    Backlog grooming includes the process of adding new users stories to the existing backlog, re-prioritizing, creating estimates for any stories that were left un-estimated and altering the large stories into smaller versions.

Roman Pilcher, Scrum trainer, and consultant emphasizes the importance of Backlog grooming in the Agile Development process. He says that the product backlog is an effective way to communicate between the Scrum team and the stakeholders. It reduces the usage of handouts and prevents the risk of miscommunication and misalignment. It helps the Scrum team to have a clear view of the requirements which helps them deliver quality products and software.

2.    The founder of Scrum Alliance suggests that teams must give 5% of their time to the backlog each day to revise. The Backlog Grooming is a preferred method by Software developers. The Scrum co-founders Jeff McKenna and Australian CST Kane refer to the practice as Story Time.




Big Visible Charts

See Information Radiator


Burn Down Chart

Plots units of work remaining to accomplish (Y-axis) against units of time (X-axis). The Burn Down Chart is a key artifact in Scrum.


Release Burn Down

The units of work appearing on a Burn Down Chart are obtained from the Release Backlog. They have been assigned an estimated point of value  during the process of Backlog Grooming. The trend line on a Release Burn Down Chart will most times trend downward, but if new items are added, then the total points remaining may trend upwards.

The Release Burn Down Chart is the basic tool a team has for visualizing the average number of points accomplished during an iteration (velocity).

Iteration Burn Down

The initial point value of work that remains in a Sprint Burn Down chart is derived from the work the team commits to accomplishing during the Sprint. The work that remains is generally graphed daily. The number of points undertaken by the teamis based on their established team velocity, i.e., the number of points the team routinely completes. In Scrum, once a sprint has begun,no new work may be added. Hence, the trend line will never rise. However, in Extreme Programming, trend line may risesince work may be added during a sprint.





See Product Owner.


Customer Test

See Acceptance Test.



The process of breaking down user stories into a smaller more executable user stories or tasks. Similarly, epics may be decomposed further into user stories, and tasks maybe decomposed further into some more fine-grained tasks. During backlog grooming and iteration planning, decomposition is usually performed and is an important predecessor to story sizing (estimation). Decomposition may also occur throughout the entire development process. In the typical product backlog, user stories that are more fine-grained grown as they near implementation and are larger and less detailed reside further down the queue.


The term got its meaning from the philosophy of mathematics and systems science, where it is employed in describing a form of analysis that is used to identify the functional parts of a system. Decomposition is also a common feature in software architecture parlance.

Definition of Done

Also: Task Complete Definition, Punch List

 This is a team’s universally agreed-upon criteria for that which makes a unit of work “potentially shippable.” This checklist of steps may include items like “documentation created”, “completed code review”, “all tests created and passing”, etc. and theymust be completed for each work unit(e.g., user story or task). The Definition of Done most time takes the form of an information radiator that is being posted prominently in the workspace of the team.

The accumulation of technical debt that arises when members of a team define done loosely and colloquially may be prevented with a well-crafted Definition of Done.

In Extreme Programming, terms like Complete Definition, a Binary Milestone or a Punch List are used to refer to the Definition of Done.




A meeting, which holds at the end of an iteration, at which the development team exhibit working software and seeks feedback from the owner of the product, management, the customer, other development teams and other project stakeholders. This meeting is called a Sprint Review in Scrum.

In his introduction to Scrum, Mike Cohn describes the format of a Sprint Review:

He said the sprint review meeting is deliberately kept very informal, typically with rules not allowing the use of PowerPoint slides and permitting not above two hours of preparation time for the meeting. He also said a sprint review meeting should not become a distraction or significant diversion for the team. Rather, he said, the sprint review meeting should be a natural result of the sprint.

In Scrum, the meeting is time-boxed to not more than 5% of development time, i.e., one hour at the close of a one-week sprint.




See Definition of Done.



A large user story awaiting decomposition into smaller stories before implementation. Epics typically are stories that are far off on the development horizon, usually lower items on the priority list. An epic story that works its way up the backlog is usually decomposed into smaller stories.

NB: In Agile, epic relates only to size. Hence, one should not be tempted to link the term ‘epic’ with importance.


Mike Cohn is responsible for coining the term epic as it relates to Agile.


Evolutionary Development

See Iterative Development.


Extreme Programming (XP)

An Agile software development methodology emphasizing transparency, customer involvement, testing and delivery of working software frequently.

The Extreme Programming standards comprise of two rights, Customer Bill of Rights and a Developer Bill of Rights, and it list its principal values as communication, courage, simplicity, and respect. XP, a developer-centric methodology, which unlike Scrum stipulates specific coding practices like Pair Programming, in which two developers work alongside each other at a single machine, unit testing(automated), and frequent integration. Another important practice in XP is refactoring or the continual enhancement of design over many iterations.

According to Kent Beck, the primary advantage of XP is that the whole process is both visible and accountable. The developers will make concrete commitments as to what they will accomplish, show solid progress in the form of deployable software, and when a landmark is reached, they will describe precisely what they did and how and why that deviated from the plan. This allows business-oriented people to make personal business commitments with confidence, to make use of opportunities as they arise and eliminate dead-ends quickly and cheaply.



Chrysler’s visionary CIO, Sue Unger in 1996, gave Kent Beck free reign to form a team whose work is to tackle the Chrysler Comprehensive.

Fibonacci Sequence

A sequence of numbers in which the next number is derived by the addition of the previous two (e.g. 1, 2, 3, 5, 8, 13, 21, 34…). This sequence is used in Agile estimation techniques such as Planning Poker to size stories.

Related links: Fibonacci Sequence

Functional Test

See Acceptance Test.



Kanban is a tool originated from lean manufacturing and is linked with the branch of agile practices loosely known as Lean software development. Just like a task board, Kanban visually corresponds to the state of work in process. However, unlike a task board, the Kanban restricts how much work in process is allowed to occur at the same time. The main aim of limiting work in process is to reduce bottlenecks and increase throughput by improving that segment of the value stream that is the subject of the Kanban. A principal difference between Kanban and Scrum is that Scrum restricts work in process through timeboxing (i.e. the sprint) while Kanban restricts work in process by restricting how much work may occur at one time (e.g. N tasks or N stories).

Relatedlinks: Kanban




In Scrum, any obstacle that prevents a developer or team from completing their work. Each member of a Scrum team answers three focusingquestions during the daily Stand Up Meeting. One of which is: What impediments stand in your way?

Impediments may comprise such things as:

  • A meeting to attend
  • A lack of technical knowledge.
  • A technical issue (e.g. a network is down).

Scrum co-founder Ken Schwaberin his 2002 book, Agile Software Development with Scrum, declared removing impediments to be “The ScrumMaster’s top priority”





Incremental Delivery

See Iterative Development.


Information Radiator

Also: Big Visible Charts

In Agile Software Development, the favorite way of displaying data visualizations is to display them on the wall in the team’s common workspace (i.e., rather than arranging them in a spreadsheet). Some examples of information radiators include a taskboard, a burn-up chart, and a burn-down chart, although chart of other types is possible. These may also be called Big Visible Charts.

One of the three legs of Scrum is to keep information visible at all timesto promote transparency.


In 2000, Alistair Cockburn made up the term “information radiator”.He introduced it in his book in 2001 titled“Agile Software Development”.



Also:  Sprint, Small Release, Time box

The uninterrupted interval of time during which an agile development team does work, usually one week to one month in length, at the end of which the team comes out with a “potentially shippable” product. This product can be a new feature or feature set, or the upgrade or expansion of an existing feature that was accomplished in an earlier iteration. Iterations in agile typically start with a planning meeting and concludewith a retrospective.


In Scrum, the iteration is called a Sprint. Extreme Programming refers to “small releases,”as iteration, using this term off and on in place of it. Dynamic Systems Development Method (DSDM) refers to iteration as a time box Etymology

Merriam-Webster Online definesiterationas a process in which repetition of a sequence of operations produces results successively closer to the desired output. This definition of iteration is broader in Agile, as the iteration may bring about either an improvement in existing functionality or a new functionality increment (or increments).

Iteration Burn Down

See Burn Down Chart.


Iteration Demo

See Demo.


Iteration Review

See Demo.


Iterative Development

Also: Incremental Delivery, Evolutionary Development, Time-boxing

A project life-cycle approach used to reduce the risk of project failure by breaking up projects into smaller, wieldier pieces of “potentially shippable” product delivered over the course of a series short-lived iterations, or sprints. Iterative development processes afford teams the capacity of “adapting and inspecting”the team’s processes between iterations and hence leading to continuous advancement. The concept of iterative development is contrasted to the conventional, waterfall method of “big design up front” along with development and testing in strict sequence.

Iterative development is a concept that is basic to all agile frame works andis treated as essentially synonymous with agile development. In Extreme Programming, it is  recommended that teams make regularsmall releases and working in iterations of one to four weeks, with a preferred interval of one week. Scrum also recommends regular cycles, referred to as sprints, of one to four weeks.


In his 1988 book titled “Principles of Software Engineering Management, Tom Gilb was the first to describe the concept of iterative software development where he referred to it as Evolutionary Development. This has gone on to permeate all agile frameworks.


On-Site Customer

See Product Owner.



Also; User Persona

A fictional character with distinct needs, goals, and habits, developed by an Agile team as a representative user, to act as a reference-point for usability during product development. Agile teams may turn over to a set of personas (the convention is to go with the English plural and not the Latin personae) as they create a product, to test if the product meets the users’ needs and desires or not.


This concept of using real characters to depict “typical users” dates back to Ogilvy, the advertising giant, which incorporated the concept in their “knowledge management system” in 1997. In his bookin 1999 titled “The Inmates Are Running the Asylum: Why High-Tech Products Drive Us Crazy and How to Restore the Sanity, Agilist Alan Cooper took the concept one step further by suggesting that the idea of “typical” needs to be dropped and a product for an individual persona should be assigned by teams.



The Inmates Are Running the Asylum: Why High-Tech Products Drive Us Crazy and How to Restore the Sanity by Alan Cooper

Personas, Profiles, Actors, & Roles: Modeling users to target successful product design an interactive presentation by Jeff Patton


Minimum Viable Product (MVP)

Though potentially confusing, the strict Lean Startup definition is the slightest thing to test to enable one cycle of the build – measure – learn loop in contrast to Minimum Marketable Feature (MMF) that is the slightestthing that delivers a user value.



Pair Programming


Agile software development technique is one in which two programmers work together at one workstation. One types in code while the other reviews every line of code as it is typed in. The typing person is called the driver, and the person reviewing the code is called the observer or navigator. The two programmers switch roles frequently.” (Wikipedia) Pair programming is one of the original 12 extreme programming practices. As counter-intuitive as it may seem to the uninitiated, pair programming is more productive than two individuals working independently on separate tasks.


Planning Poker:

This is a tool in Agile used for task estimation. As a structure game, it is used to reach group consensus as well. The name poker was suitable because it  involves a deck of cards.

Game Play: in planning poker, each of the cards in the deck comes with a number in  Fibonacci sequence, and each number equals the previous two put together, e.g: 1, 2, 3, 5, 8, 13, 21, etc. Every member in the team chooses a card that duly represents their best guess as to the difficulty level of the task, and everyone turns their cards over at once. The low and high cards in the desk gets the floor to decide their fate, then the game would be  repeated. The theory being that the players’ estimates will converge through rounds of structured discussion. In the game, a Project Manager or Scrum Master may serve as moderator.


The game was first created by Agile consultant, James Grenning, an original signatory to the Agile Manifesto in 2002 while working with an XP Team; and it was later popularized in a book titled Agile Estimating and Planning by an Agile consultant and Certified Scrum Trainer Mike Cohn.

Posted in pLeave a comment


Also: Agile Principles

 Agile Principles, just like the Agile Values, were first stated by a group of independent software development pundits who gathered in 2001 at the Snowbird resort in Utah as to codify their shared philosophy. The result was an Agile Manifesto, the signatories to which formed the basis of the Agile Alliance. The Manifesto consisted of set of Valuesand their supporting principles.

Below are the twelve principles in a list:

  1. Our highest priority is to satisfy a customer with early and continuous delivery of valuable softwares.
  2. Welcomes changing requirements, even late in development. Agile process harnesses changes for the customer’s competitive advantage.
  3. Delivers working softwares frequently, from a couple of weeks to a couple of months, and with a preference to the shorter timescale.


  1. Business people and developers must work together daily throughout the project.
  2. Build projects around motivated individuals; give them the environment and support they need, and trust them to get the job done.
  3. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  4. Working software is the primary measure of progress.
  5. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  6. Continuous attention to technical excellence and good design enhances agility.
  7. Simplicity–the art of maximizing the amount of work not done–is essential.
  8. The best architectures, requirements, and designs emerge from self-organizing teams.
  9. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.



The Agile Principles were originally stated in the Agile Manifesto.

Posted in pLeave a comment

Product Backlog

See Backlog.

Posted in pLeave a comment

Product Owner


The Product Owner is the primary author of the user stories, who owns the product backlog, prioritizes the stories, writes acceptance tests and accepts work completed by the team. On some teams, the product owner may act as a liaison between stakeholders and the team, communicating the vision of the product while ensuring the team stays on track to meet the customer’s goals. On other projects that are relatively large, the role can be played by a Product Manager. In Extreme Programming, the preference is for the On Site Customer to be an actual customer, not a stand-in.

Customer, or On Site Customer:

This, as regards Agile development team is the real customer, end user, a stand-in for the customer or end user; a non-coding team member who has a complete grasp of the requirements and business value of the product is responsible for prioritizing work for the team.

Agile coach Simon Baker elegantly described the role of the Product Owner: “You must recognize that through your actions – writing user stories and acceptance tests, prioritizing user stories by business value, deciding which user stories are developed next, providing rapid feedback, etc – you are effectively steering the project and are ultimately responsible for the business value that is delivered. As the driving force behind the project, your presence must be visible, vocal and objective.”

Tip: Some agilists makes fun of referring to the Product Owner as the “single wringable neck” on a team—the person who bears responsibility for the team’s failure to meet it’s sprint or release goals. However, there is a great deal of disagreement in the professional community as to whether this notion is truly Agile, so we do not consider this level of ultimate responsibility to be native to the role’s core definition.

Certified Scrum Product Owner is a professional designation offered by the Scrum Alliance, obtained by completing a two day introductory course and passing a one hour exam.


The term Product Owner is commonly used across agile frameworks, but is native to Scrum. In extreme programming, the role is referred to as Customer, or On Site Customer.

Release Backlog

See Backlog.

Posted in rLeave a comment

Release Burn Down

See Burn Down Chart.

Posted in r1 Comment

Release Plan


The release plan is a schedule for releasing software into productive use. Typical release plans include the key features to be delivered, along with corresponding release dates. Release plans may also expose key milestones or dependencies that parallel project activities. In agile development, release plans can be mapped back to the iterations (or sprints) that implement the released features.

Related links: Release Plan
See also: Release Planning

Release Planning

Release planning is a planning process that is an integral part of the Agile Software Development. It is one of the five levels of planning whose main purpose is to plan activities that can aid in increasing the value of a product. Activities include projecting the level of effort in terms of the number of repetitions made, that will be necessary to deliver the desired features. This is typically done by extrapolating the current status of the development effort yielded by team performance on the basis of their pace that gets work done. Measuring the velocity helps you set appropriate objectives while planning for iterations and releases. A release planning meeting that brings together this team to have a planning session that determines features, themes, key dates and milestones to be achieved in a specific time frame.  The team provides insights into technical feasibility and dependencies.


A time boxed meeting held by a project team after a certain number of iterations, or at the end of a release, in which the team analyzes the success and improvements required for future projects. The retrospective is a major element of agile team’s ability to “inspect and adapt” in the pursuit of “continuous improvement.”

The Agile retrospective has a manifesto that circulates around ‘lessons learned’,  where the goal is not to generate a comprehensive list of what went wrong but to generate a positive outcome from the retrospective  meeting and identify two high priority action items that needs to be worked on until the next iteration or release. They emphasize on actionable items rather than comprehensive analysis to stay focused on an effective strategy.

Retrospectives may take many forms, but there is usually a facilitator, who may or may not be a member of the team, and the process is broken down as following: set the stage, gather data, generate insights, decide what to do and close the retrospective. Retrospective facilitation is a distinct skill set, and there are many formal tools and exercises that may be used to gather and analyze the team’s data, many of which are described in detail in the most widely recognized handbook: Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larson.


Norman Kerth’s work is highly valued as he penned down the methodologies that structured agile retrospectives in 2001 in his book, Project Retrospectives: A Handbook for Team Reviews: “Wayne and Eileen Strider, two fellow facilitators, suggested that we call what we do a retrospective.  The word seemed appropriate; it didn’t carry any loaded meanings and it could be applied to projects without implication of success or failure….” The Ninth Agile principle suggests that having a regular agile retrospective is one of the most important of agile development practices.


Scrum is an iterative and incremental structure for the agile software development. Scrum is the most widely recognized agile framework, and is compatible with other agile practices like Extreme Programming and Test Driven Development. Scrum emphasizes on delivering results from the obvious rather than speculation. Time is divided into short work intervals, known as sprints, typically one week or two weeks long. The product is kept in a potentially shippable (properly integrated and tested) state at all times. At the end of each sprint, stakeholders and team members join in to see a demonstrated potentially shippable product increment and plan its next steps. Scrum has three major roles which include: Scrum Master, Product Owner, and Team. Time-boxed ceremonies (Daily Scrum, Sprint Planning Meeting, Sprint Review and Retrospective), and artifacts (burn down charts, product backlog).

Usage: We’ve chosen to develop our new product using Scrum.

A “scrum” or “daily scrum” is a 15 minute-long status meeting.

 Usage: Floyd, the new project manager, was invited to observe our daily scrum.

Tip: You will sometimes hear the term Scrum used interchangeably with the term Agile, but this is incorrect. Agile is not a substructure, but it is rather a broader set of values and practices, while Scrum is a specific order that finds itself under the agile sector. According to the Scrum Alliance, Scrum is often seen in capitalized form (SCRUM), but it is incorrect to refer it that way as it is not an acronym.


The term “Scrum,” as it is commonly applied to software development, began its life as a sports metaphor. The term “Scrum” is short for scrimmage, it became famous in 1857 associated to the game of Rugby, and where it refers to a team as one body tries to go a distance on the field.  Scrum was also introduced as a metaphor for industrial processes in 1986 by two Japanese academics known to be Hirotaka Takeuchi and IkujiroNonaka who used this term to describe a new, flexible approach in a paper titled “The New Product Development Game.”

The early 90’s had a few circumstances that conspired in bringing the term “Scrum” into use within the agile development community. In 1991 Peter DeGrace and Leslie Hulet Stahl published a book called “Wicked Problems, Righteous Solutions: A Catalog of Modern Engineering Paradigms,” which contained an intense analysis directed towards the “waterfall” method for software development a. DeGrace and Hulet Stahl quoted Takeuchi and Nonaka’s industrial paper as a possible restoration.  Sutherland, John Scumniotales and Jeff McKenna, used the term Scrum to describe the new foundation they were trying to surface based on values and principles that were related to the Agile Manifesto. Alternatively, Ken Schwaber was developing something similar to Advanced Development Methods in its company. The two teams were aware of each other’s work so later in 1995; Schwaber and Sutherland jointly authored a paper that formulated the basics of their previous work. The collaboration of Schwaber and Mike Beedle was aimed at Agile Software Development with Scrum, which is widely accepted as the definitive text. Schwaber figured out his way to find the Scrum Alliance, which is now the certifying body for Scrum trainers and practitioners of all levels, and the primary source of authoritative information on the state of Scrum as practiced today.

Scrum Board

See Task Board.


Small Release

See Iteration



Spike acts like an indicator story or task aimed at answering a question or gathering information, rather than at producing shippable product. Spikes come in two forms technical and functional and they are usually demonstrated at the end of iteration. Sometimes a user story is generated that cannot be estimated until the development team does some actual work so It is used to reduce the technical approach to understand the true requirement. The spike is then given an estimate and included in the sprint backlog like in any other story or task.


The term spike comes from Extreme Programming (XP), where “A spike solution is a very simple program to explore potential solutions.” Ward Cunningham who is the XP guru describes how the term was conceived on the wiki: “I would often ask Kent [Beck], ‘What is the simplest thing we can program that will convince us we are on the right track?’ Stepping outside the boundary to let something evolve often leads to the creation of simpler and more compelling solutions. Kent labeled this as Spike. I found the practice quite enticing as it still called out large frameworks.”



See Iteration.

Posted in sLeave a comment

Sprint Backlog

See Backlog.

Posted in sLeave a comment

Sprint Review

See Demo.

Sprint Planning Meeting:

Every single Sprint starts with a twin planning meeting: first, the solid tasks as regards the coming sprint, and secondly, the activity that identifies and prioritizes stories. The twin, otherwise two-part meeting is made to last for four hours in a two-week sprint, while the four-week (that is one month) sprint apparently goes on for about eight-hours. The spring planning meeting results, and equivalent to the weeks in a spring when multiplied by two hours; that goes as the standard. To break it down:

  • A side or part of the sprint planning meeting stands as the moment that the product backlog is reviewed, and the  product owner would at the time describe the agenda and task for the next sprint. While the meeting last, the team seizes the opportunity for precision, and as well engaging in some other sprint objective discussions.


  • On the other side of the  planning meeting, the output is always the sprint backlog. During this meeting, the product owner is mandated to stick around, and the team would decide on how the work should be built. They would start the decomposition of the product backlog items, arranging them into work tasks and appraising in hours.


Relatedlinks: Sprint Planning Meeting


Stand-Up Meeting

Also: Daily Scrum, Scrum

This is an all-and-sundry short meeting in which every member of agile represents himself in tackling the three questions of:
What have you been able to achieve since the last stand-up?

What can you present by the next stand-up?

Do you suffer any obstruction of whatsoever?

In this meeting, the team members’ stands shoulder to shoulder while forming a narrow circle, and the time and venue remains the same daily. The meeting at times is regulated with a countdown timer which is usually set to nothing more than 15 minutes, while the purpose of standing up is to maximise and efficient time, putting out any form of distraction. The strength of this strategy is the team-mate relations via exchange of information. For the meeting, the attendance is limited to the development team members which are able to endure to standing. The relevance of the  meeting goes towards raising the transparency of everyone's  work and at the same time ensuring work integration.


This is known as the Scrum or Daily Scrum, in Scrum where it was adapted to. It is originated with Extreme Programming and the daily stand concept.

Posted in sLeave a comment


An outsider who registers interest in the team's work outcome through meeting an outlined  requirement.

Related links: Stakeholder
See also: Chicken



See User Story.


Release Plan:

This is simply a schedule for the release of a software into the productive use. The dates of  release, and the key features are typically included in the release plan. This release plan might likely reveal the key dependencies or milestones that forms a project activity. In the agile development, a release plan can be mapped back to the sprints (or iterations ) that implements the released features.

Related links: Release Plan
See also: Release Planning



In Scrum and Extreme Programming are works, or a unit of work as the case may be, estimated hourly. User stories, during the iteration planning meeting, are decomposed into task(s). Ken Schwaber, In one of his books -Agile Software Development with Scrum- writes, “Tasks should have enough detail so that each task takes roughly four to sixteen hours to finish.”

Many Agile practitioners differ  from this formula in practice; some of this folks don't decompose the stories into task, not at all, and they rather add the user stories to their      task board directly. They  prefer extra abstract sizing units and extra granular points to hours (e.g., story points).



Etymology Resources

Agile Software Development with Scrum by Ken Schwaber and Mike Beedle

Iteration Planning on


Posted in tLeave a comment


These are the real work descriptions done either by a pair or an individual for story completion. These sets are flexible and free. All tasks are to be completely verified, although per story they are several typically; the attributes that follows below comes with tasks usually:

  • The work to be performed clearly explained in any term, be it business or technical.


  • The amount of time, in estimation required for the work.


  • Work owner, whether pre-assigned or not.


  • A verification and exit method (in inspection or test)


  • A pointer of the person responsible for  verification


Relatedlinks: Task


Task Board

Also Scrum Board

This is a type of information radiator that presents, the “to do” “doing” and “done” columns at minimum for a team’s work organizing. Some teams includes their backlog as a column on the task board, and others limits it to work in other to be performed during the current iteration.  The task board is ideally a physical thing, that consists of sticky or note cards affixed to a wall, even though an online task board application can be used by the distributed team. Other Agile teams may populate the Scrum Board with User Stories, while in Scrub it is populated with tasks for the current sprint.




The term Task Board derives from Scrum.

Posted in tLeave a comment

Task Complete Definition

See Definition of Done.

Posted in tLeave a comment

Technical Debt:

This is a term that was coined by  Ward Cunningham in a bid to describe some obligations incur by a software organization when it choose a construction or design approach that seems expedient on the short run, which, with time  increases complexity on the long run, becoming more expensive as a result. Incurring or not incurring a technical debt is a tradeoff decision made ideally at the point work occurs in such  deliberate manner.

See also: Refactoring


Timebox, Timeboxing


See Iteration and Iterative Development.

Posted in tLeave a comment

Test-Driven Development

(Credit- Ken Beck)

DD for short is a kind of development process for software, which depends on a very short development circle repetition. To start with, the developer writes an automated failing test case to define a new function and desired improvement, following with the code to finally refractor the new code produced and passes it to an acceptable standard. (Wikipedia


User persona: User persona describes a model user of a system, an example of the type of individual who would communicate with it.

The concept is that if you want to plan effective software, then it must be designed for a particular person.

Simply, user personas signify fictitious people which are created on your knowledge of actual/real users.

You may not be in a position to interview all the real consumers of your product, but you can get reasonable estimates through personas.

Moreover, to check whether or not the product encounters the user’s demands and needs, agile teams are able to refer back to a set of personas as they gene



"Förmåga att se helhet & affärsnytta på ett unikt sätt.

Fastnar inte i detaljer utan ser till att projekt genomförs"

- Fredric Knutson, Chef Försäljningsspecialister ICA Sverige AB

Kunden gillar

Vi har alltid som mål att jobba nära dig som kund, hålla en personlig service och uppnå affärsnytta för din organisation och i dina Business Intelligence satsningar.


Vi gör det möjligt för dig att prata direkt med våra kunder om våra tjänster. Det här är ett sätt för oss att visa att vi är trygga i det vi gör men främst ett sätt för oss att skapa en trygghet för dig innan du väljer oss som partner.


Kontakta oss gärna för fler referenser



Bli en av oss

Vi letar alltid efter duktiga, motiverade personer med förmåga och drivkraft att göra de bästa möjliga för kund. Oavsett om du är en stämningsskapare eller en senior person med tjugo års erfarenhet så vill vi ha kreativa, engagerade, intressanta människor som inte är rädda för att tänka nytt, älskar utmaningar och som vet att de kan göra stor affärsnytta för kund. Det krav vi har är att du ska ha en teknisk bakgrund och ha senior erfarenhet. Mindbase grundprinciper kan forumelras som "hos oss frågar du inte om lov, du frågar istället om råd".

På Mindbase, brinner vi inte bara för att göra fantastiska lösningar vi vill ha roligt när vi gör det också! Förutom att skapa en rolig och utvecklande arbetsmiljö, har vi några stora fördelar… Nu söker vi agila projektledare och Scrum Masters så klicka på kontakt nedan, fyll i dina kontaktuppgifter så bjuder Peter in dig på en trevlig frukost och berättar mer.




Upphovsrätt © Mindbase AB. Alla Rättigheter Reserverade