CivicActions' Common Vocabulary

Definitions

  • Agile - Any way of working that adheres to the tenets of the Agile Manifesto. Agile web development is based on iterative development, allowing for just-in-time-planning at the beginning of each sprint, and the highest value items being worked on first. The teams are self organizing and cross functional. The iterative approach minimizes risk by having something to show to stakeholders after each sprint and allowing the team to adapt to stakeholder requests to change or add requirements.
  • Agile Coach - Individual who teaches or mentors the teams who implement Agile. The goal of an Agile coach is to help teams to produce the best results by practicing Agile.
  • Agile Manifesto
  • Individuals and interactions over processes and tools.
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan
  • That is, while there is value in the items on the right, we value the items on the left more.
  • Agile Process - Since Agile is "people and interactions over processes and tools" we prefer to talk about our Agile Practices. To us, Process feels more static, and loses the important "inspect and adapt" aspect of how we work. However, we acknowledge that the term Agile Process is used within the Agile community in a way that it is interchangeable with Agile Practice.
  • Agile Methodology - See "Agile Process". Like Process, Methodology feels static, and loses the important "inspect and adapt" aspect of how we work. The term is used within the Agile community, though, in a way that is interchangeable with Agile Process and Agile Practices.
  • Agile Practices - Represents our commitment to "people and interactions over processes and tools" by using the Agile tenets and placing a high value on the "inspect and adapt" aspect of how we work.
  • Agile Anti-pattern - way of working that is NOT Agile, but seems to be a common mistake that people make. Examples include: "We didn't have time for QA in the sprint, so we're doing it after the sprint." "My ScrumMaster/Product Owner / Manager assigned me this task."
  • Artifacts - Tangible items developed as part of an Agile/Scrum practice: Burndown Chart, Product Backlog, Sprint Backlog.
  • Balance Score - On a scale of 1 to 10, in the present moment, how are you doing at knowing and honoring your priorities in your professional, personal, and spiritual life.
  • Best Practices - Taking what we've learned to be successful and continuing to apply and refine it for optimal results. This could apply to how we communicate, how we write QA tests, how we approach problems, how we code, among other things. It also applies to what we do: daily scrum calls, regression testing, using email lists, among other things. A practice is always subject to inspection and adaptation. Ideally, best practices are documented - in some place that can be easily updated when they change - so that they can be easily pointed to, learned from and reviewed. Note that best practices are not "rules" but rather "guidelines" that have been refined and found to work in many cases.
  • Burndown Chart - This chart is updated each day, typically by the ScrumMaster. Its purpose is to be a public and highly visible representation of remaining time/work in the sprint. CivicActions also includes a budget burndown that indicates how much time each team member has committed to within the sprint, where they should be in that commitment as of today, and where they actually are as of today.
  • CivicActions Project Framework - A Trello Board that lists project-specific tasks that we MUST do for each project as well as lists of tasks we "could" undertake for project strategy, approach, discovery, tools, scrum framework, PM, engineering and training needs. Our goal is to use the Project Framework board to remind ourselves of things we have tried in the past and things we have learned, so that we can leverage this to set future projects up for success.
  • Code Blue - Code blue is when all hands on deck in the company re-prioritize activities to focus on sales, marketing, and delivery. Most often this means as many hands on deck doing billable work as possible.
  • Context - Purpose - Results (CPR) - A CPR (which stands for Context, Purpose and Results) is a mechanism (which is really just a document structure or outline) to declare the outcomes and intentions of any activity, whether it's planning your day, or guiding a massive project involving hundreds of people over several years. To create a CPR, you start with writing the RESULTS in the past tense, as if they'd already occurred. Next, the PURPOSE statement is structured to tie results into a vision statement that provides a clear and inspiring description of WHY the project exists and the impact it has. i.e.┬áThe purpose of "a" is "b" through "c" so that "d". Finally, CONTEXT, a summary of the vision and results into something that touches the essence of the project and its intentions.
  • Cost - Complexity - Impact - When deciding upon various strategies, we often take a list of all of the ideas (strategies) that one could envision in order to meet some objective (vision). This list is assembled into a spreadsheet where we quickly score each strategy with high, medium and low. After quickly scoring all ideas, we look at the strategies that are highest impact and lowest in cost and complexity to prioritize which items we intend to consider for further studying or implementing.
  • Daily Check-in / Daily Stand-up / Daily Scrum - A very short time-boxed meeting (usually 15 minutes) in which sprint participants answer the following questions: "What did I accomplish yesterday?", "What will I do today?", "Do I have any blockers impeding my progress?" At CivicActions we prefer to extend the "What did I accomplish yesterday?" question to include "How much time did I spend?" Ideally, this meeting takes place daily, is at the same time and location, and all team members attend. We actively encourage our client Product Owners to attend this call.
  • Definition of Done - A clear list of required tasks or requirements that must be completed before an item can be called done. It is created by the team and should not change during a sprint.
  • Deliverable - a tangible output, document or piece of work.
  • DevOps -

    @todo Add this content

  • Dot Voting - a technique where team members list topics or items in some manner (on sticky notes, in a spreadsheet, on a Trello board). After gathering all items, each group member has a certain number of votes that they can cast. Items are prioritized according to the number of votes.

  • Escalation - A determination that a project's success is potentially at risk, and a call for assistance to help address the blockers to the project. Frequently, but not always, related to a project's Primary Constraint (budget, scope, or timeline).
  • Iteration - A cycle of time in which some portion of a project's sum deliverables are completed, often measured in accordance with the Sprint timeline. Iterative release is a technique used to maximize efficiency and keep work focused on the project's objectives.
  • Kanban - An Agile framework in which the Product Owner can slate tickets throughout the cycle, negotiating with the project team on the size of tickets, since the number of tickets in a Kanban cycle is fixed. The team must collectively limit the amount of work in progress, eliminating bottlenecks, and track the timing of tickets' progress.
  • Layers - Layers is a framework for prioritizing some of our business decisions. Layers begin with a vision, then next strategy, and finally implementation. We use this to guide our collaborative brainstorming work to make sure that we are aligned in our actions.
  • Lean - The core idea is to maximize customer value while minimizing waste (including unnecessary practices, documentation etc.) to deliver quickly. The idea comes from Lean Manufacturing and has manifested into Lean software development and Lean business practices (The Lean Startup book).
  • Lean Canvas - A way to encapsulate the idea (an overview of the business plan) for a product or service for a Lean Startup in one page, developed by Ash Maurya. Ash writes why he created a different adaptation to the original Business Model Canvas by Alex Osterwalder.
  • Lean Coffee - A discussion format. Users brainstorm topics for discussion then dot vote to prioritize them. The top priority item is discussed for a set number of minutes. When that time is up the group holds a Roman vote to decide whether to continue with that topic for another set number of minutes or move onto the next topic.
  • Lean Manufacturing - Management Philosophy derived mostly from Toyota Production Systems (TPS). Centers of "preserving value with less work".
  • Lean Startup - Based on a book by Eric Ries, a way of developing products and services in extreme uncertainty. Uses the "build-measure-learn" loop to test hypotheses about what problems a customer or user is trying to solve and whether they will engage with a product or service to solve that problem.
  • Minimum Viable Product (MVP) - An MVP is a learning tool (NOT beta product) to determine if a business idea is actually worth pursuing. It is an experiment, a feature or a collection of "just enough" features to be deployed and assessed, but no more. An MVP's value is in the feedback that can be gathered to understand what the audience actually needs. It's important to note that the MVP often does not take the form of built software, but rather can be a conceptual model intended to facilitate discussion. Reading Materials: The disposable MVP. Ignite Talk by Lean Start Up Machine
  • Primary Constraint - The parameter that the Product Owner has determined is most important and least mutable: Budget, Scope, or Timeline. Once it is defined, the project will be managed to this primary constraint, which could impact the other two parameters.
  • Product Backlog - The known list of the user stories, outcomes, requirements, tasks, bug fixes that remains to be complete for the project. The Product Owner prioritizes the backlog so that the team always works on the most valuable features first. It is ever-changing and growing as business needs change and as new technology becomes available.
  • Product Owner (PO) - The Product Owner represents the voice of the stakeholder and holds the vision of the outcomes on their behalf. This person ensures that the Scrum Team works on the features and functions that bring the most value to the organization. The Product Owner owns the Product Backlog and is the subject-matter expert, with comprehensive knowledge about the business value that each part of the product will create for the organization.
  • Prototype - A model for the testing of a concept and clarification of objectives, released for review early in the development process. There are several variants of prototyping, which are not necessarily mutually exclusive with most Drupal projects, as some components could be featurized and re-used (evolutionary) and others might be throwaway.
  • Rapid/Throwaway Prototype: creating a working model of various parts of the system at a very early stage, after a relatively short investigation. The method used in building it is usually quite informal, the most important factor being the speed with which the model is provided. The model then becomes the starting point from which users can re-examine their expectations and clarify their requirements. When this has been achieved, the prototype model is "thrown away". and the system is formally developed based on the identified requirements.
  • Evolutionary Prototype: The main goal when building an Evolutionary Prototype is to build a very robust prototype in a structured manner and constantly refine it. The reason for this is that the Evolutionary prototype, when built, forms the heart of the new system, and the improvements and further requirements will be built.
  • Parallel Prototyping: A product is built as separate prototypes. At the end the separate prototypes are merged in an overall design.
  • Quality - Uber-term to describe our commitment to quality in all aspects of our work, from the high standard of the services we provide, the code we write, and the Quality Assurance process, through the communications we have with each other as a team, our interactions with clients and outside vendors and the depth of the relationships we build.
  • Quality Assurance - The testing of the work completed against the task requirements to ensure that the goals and expectations of the work delivered meets what was agreed upon, and also to ensure that the system as a whole continues to be working as expected. Testing could include manual and automated testing, utilizing QA engineers, QA software tools and end users.
  • Red, Blue, Black - Colors that represent functional areas of the business. Red means administrative. Black means strategic. Blue means revenues (sales, marketing & delivery).
  • Regression Testing - Testing that seeks to uncover new bugs or issues in existing areas of the site that may have occurred after enhancements, improvements, configuration changes or other work has been completed. The purpose of regression testing is to ensure that new problems have not arisen as the result of all of the above. Specific Regression Tests are written as part of a test plan, and are tested before and after each release.
  • Risk - A future uncertain event with a probability of occurrence and a potential for loss that could negatively impact the project, timeline, budget, work, team, and/or company.
  • Risk Management - The process of identifying risk, defining a response to it, and tracking it until closure. Risks can be on a project level (estimates, time frame, budget, value, quality, impact) or on an operation level (reputation, balance sheet, retention).
  • Roman Vote - All team members vote thumbs up (agree), thumbs down (disagree), or thumbs neutral to assess the will of the group and decide something. See synonym: Dot Voting.
  • Scrum - An iterative project framework within Agile. The framework defines roles (ScrumMaster, Product Owner and Scrum Team) and artifacts (Product Backlog, Sprint Backlog, Burndown chart) and timeboxed rituals (daily stand up, sprint planning meeting, sprint review meeting, Sprint). CivicActions' practices are based on Scrum.
  • ScrumMaster - Certified ScrumMasters (CSMs) help project teams properly use Scrum, increasing the likelihood of the project's overall success. CSMs understand Scrum values, practices, and applications and provide a level of knowledge and expertise above and beyond that of typical project managers. CSMs act as "servant leaders," helping the rest of the Scrum team work together and learn the Scrum framework. CSMs also protect the team from both internal and external distractions.
  • Sprint - The basic unit of development in Scrum; a timeboxed effort preceded by a Sprint Planning Meeting and followed by a Sprint Retrospective. Usually 2, 3, or 4 weeks in length, determined at the outset.
  • Sprint Backlog - This is a subset of the Product Backlog and is defined as the work that is to be accomplished within the current sprint. The Product Owner will identify the top priorities from the Product Backlog and the team agrees which items from there they can bring to the Sprint Backlog. The items brought over are then broken down by the development team into smaller tasks if necessary and the Sprint Backlog is prioritized. No items can be added or removed from it once the sprint starts. Not everything in the Sprint Backlog may get completed in the sprint, although it is the intent.
  • Sprint Board - A Trello board that contains the cards of a particular Sprint's backlog, and allows the Scrum Team to track progress from inception of work, through QA and bugfix, to "done". The board may make reference to, but should not include, the entire Product Backlog.
  • Sprint Planning Meeting - A meeting between the Product Owner and Scrum Team, during which the PO elects tickets/cards from the Product Backlog for inclusion in the Sprint (precondition being a backlog comprised of annotated and estimated tickets/cards). The team asks clarifying questions during this meeting in order to be able to estimate the work and write implementation plans.
  • Sprint Review / Demo: A timeboxed meeting in which the completed work delivered in a sprint is demonstrated.
  • Sprint Retrospective: A timeboxed meeting in which the work performed and delivered in a past sprint is evaluated, and possible improvements to the team's practices are identified (hypothesized).
  • User Acceptance Testing - The process by which a representative of the client team follows an explicit set of steps to test the requirements of the ticket in order to mark it "Done".
  • User Epic - a group of related user stories
  • User Story - one or two sentences in everyday language that captures the who, what and why of a story: Independent, Negotiable, Valuable, Estimable, Small, Testable (INVEST) requirement: As a , I want to , so that .
  • Velocity - describes how much work a scrum team can accomplish in a sprint. The longer a team works together, the more efficient they become. The scrum team can look at past sprints to gauge how much work is likely to be accomplished in a sprint.
  • Work in Progress (WIP) - a partially finished task or ticket. Limiting WIP items increases the velocity that an item passes through a system.

Resources

  • Agile Alliance - The Agile Alliance is a nonprofit organization with global membership, committed to advancing Agile development principles and practices. Agile Alliance supports those who explore and apply Agile principles and practices in order to make the software industry more productive, humane and sustainable.
  • International Consortium of Agile (ICAgile) - An organization founded to drive high-quality, credible Agile education that teaches professionals to approach Agile in any context, rather than training to follow a specific methodology (Scrum, XP, etc).
  • Scrum Alliance - a non-profit organization offering resources, certifications, training, and support for individuals and organizations in Scrum.

Words needing definitions

  • Validated Learning -
  • Hypothesis -
  • Success Metric - (or some other way of talking about metrics... such as the Lean distinction between vanity and actionable metrics)
  • Maintenance Sprint -
  • Tech Lead -
  • User Experience -
  • Information Architecture -
  • Responsive Design -
  • Outcomes -
  • SDLC (Software Development Life Cycle) - (utilizing best practices, source code control, dev-qa-live and ongoing maintenance processes)
  • POC - Proof of Concept