ITS Administrative Computing

Systems

Services

System Overviews

Help




Password Reset

Microsoft Ending XP Support

Submit a service request online

Glossary - ITS Iterative Framework

Jump to: A | B | C | D | E | F | G | H | I | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z

A

Agile Methodology
Agile Methodology refers to a group of software development methodologies that are based on principles of iterative development where requirement evolves through collaboration between self-organizing cross-functional teams.

Automated build
An automated build is when all checked-in code is part of a build.

Automated testing
Automated testing is a way of building quality into the software by reducing the ongoing testing effort. It also helps to build confidence in the code and in the team to make changes late in development by providing feedback to what effect the changes have on the existing code.

return to top

B

Behavior-driven development
Behavior-driven development (BDD) is an evolution of training-driven development (TDD) that seeks to write tests that can be understood by both the development team and the business. BDD relies on the use of a very specific, small vocabulary to minimize miscommunication and to ensure that all participants—the business, developers, testers, analysts, and managers—are of the same understanding and using a common language. Learn more...

return to top

C

Conceptual object model
The conceptual object model describes the entities or objects in the system and the relationships between them. It does not include specific attributes or table properties.  The object model informs the data model and must be as complete as possible prior to beginning database and/or application development. View Sample Conceptual Object Model

Continuous integration
Continuous integration (CI) is the practice of periodically executing automated build scripts (ABS), preferably in short intervals.  When combined with a comprehensive suite of unit tests, CI helps prevent integration problems by encouraging developers (and testers) to make frequent check ins.  Since the build executes all unit tests, it identifies integration problems early for an immediate fix. Learn more...

return to top

D

Daily stand ups
Daily stand ups occur at a regular time and are meetings where project staff members quickly—within 30 seconds—communicate what they will be working on that day. They individually call out any issues that need to be resolved with other staff after the meeting. It is best practice to pass a token or icon to identify who is speaking and have the team physically stand next to the wall. Learn more...

Data model
A data model documents the informational needs of the system. It lists the data attributes needed to satisfy functional requirements. A data model will also portray the logical structure of data independent of the data design or data storage mechanism. It is the basis for designing the physical data structures (tables and rows) of the system.   Learn more...

Develop phase
The develop phase focuses on keeping code simple, testing often, delivering functional bits of the application as soon as possible, getting feedback, and responding to feedback, as appropriate. The goal is to build upon small, client-approved parts as the project progresses rather than delivering one large application at the end of the project. This objective is accomplished by keeping the build up to date. Learn more...

Direct observation
Direct observation is an activity that involves watching stakeholders performing their jobs in the workplace in order to understand how software will be used in its work context. Direct observations define ‘As Is’ business processes and uncover details (workarounds, solved problems) that might not be obvious when stakeholders describe tasks and activities that are often second-nature to them. Direct observation is not necessarily the same as an interview. The interview focuses on conversation, while the direct observation focuses on observation.

Domain walkthrough
(see Story card walkthrough)

Done done
Done done indicates that the stakeholders can use the final product as they intended and that the work is finished, tested, and production ready.

return to top

E

Estimate sheet
The estimate sheet is a written document that includes the following:

  • name and role of the project team member
  • project name
  • names of story cards for that iteration
  • estimating factor
  • risk rating
  • section to record the median estimate

View sample

Estimating / estimating meeting
An estimating meeting is conducted to review story cards and provide estimates to prepare for future iterations. An estimating meeting occurs once per iteration. An estimate should not take more than 1 to 2 minutes per card, it is a best guess based on the information at hand. Ideally, multiple estimates should be captured (if possible) and the mean estimate per card is captured. Learn more...

return to top

F

Fail fast
Fail fast is an approach to mitigating uncertainty through proving ideas out by actually trying them sooner than later, by learning from the outcome, and by making adjustments as necessary. Learn more...

Feedback loops
Feedback loops support collaboration and communication by allowing the various stakeholders visibility into the development process. A handful of these are small-scale practices that further drive large-scale practices. Small-scale practices support and strengthen large-scale practices by providing high-quality input. The small-scale practices combine to create the inmost of three nested feedback loops driving effective agile development. This deepest feedback loop drives the creation of well engineered software, which is critical for success in any project. Learn more..

return to top

H

Horizontal planning
Horizontal planning promotes detailed planning for the short term and broader planning for the future. Detailed tasks may be planned for the next month, but only the project vision is valid for the six month horizon.

return to top

I

Informative workplace
The idea of Informative workplace is to build feedback mechanisms that support the daily work of an agile team. These mechanisms can be visual displays that the team manually updates such as using colored dots on story cards to signify status changes,  using the wall to communicate assignments, using daily stand ups to share information or electronic devices such as lava lamps  or audio signals  linked to automated processes.

Interviews
Interviews are face-to-face meetings with stakeholders. The interviewer asks questions to collect information about stakeholder needs. Interviews identify a wide range of requirements topics such as business goals and priorities, stakeholder tasks and data requirements, and the environment in which business processes are executed. Interviews probe what a business process should be after the project is successfully completed. Interviews also help identify additional sources of requirements information. Learn more...

Iteration 
An iteration is a collection of story cards that are scheduled and authorized to work on. An iteration length of one to four weeks is acceptable based on team throughput and allows the project team to mitigate risk by delivering business value early and regularly. This helps to promote small feedback loops that in turn help the stakeholder and team make course corrections early in the development process.  Iterations should be as short and sustainable as possible.

Iteration forecast
An Iteration forecast is a top down view of story cards grouped by project goals or phases that are scheduled across multiple iterations and multiple releases for the entire project. This planning activity is helpful when release dates are fixed and scope and/or resources can be adjusted to meet the fixed release dates.  The Iteration forecast is a deliverable that can be shared with stakeholders to communicate release dates, resource capacity, and high-level iteration schedules within each release.'

return to top

L

Last responsible moment
This is the principle that you should put off making important, irreversible decisions until the latest, responsible moment so the team can have the most current information to make the decision.

Less code
Less code means coding only what it is necessary. It avoids over architecting. Less code means developing code only for story cards that really add business value and writing only what is needed for a given story. Less code means coding the bare minimum to express the prioritized stories without guessing ahead and building reusable code that may not be a priority.

return to top

M

Make it Fast
This phrase means that once tests are passing and code is clean to focus on performance tweaking. Use of a profiler is recommended, if possible. Any tests will ensure that functionality is not broken. These steps can be executed one after another or spread over time (across iterations and depending on the story) as the project progresses.

Make it Right
This phrase refers to focusing on refactoring the code once the feature is working (all tests passing). The tests will provide the necessary feedback and allow for clearing up structural and aesthetic issues, removing duplication, renaming variables, and so on.

Make it Work
This phrase refers to programming with your mind focused on the story's basic behavior and just making the feature work. It ensures that all tests pass for a given story.

Monitor and Control
A set of activities and approaches for monitoring assigned work, for communicating progress, and for addressing issues within the project team. Monitor and Control acts as a medium for confirming work completeness with the stakeholders. Learn more...

return to top

P

Parking Lot
Parking Lot refers to stakeholder-approved work that can be pulled ahead if all work within the planned iteration for that lane is complete and all other lanes are on target.  Story cards in the parking lot are displayed outside of the lanes, on the wall. If parking lot story cards are not worked on, they are re-estimated and prioritized with all other story cards as part of the planning game for the next iteration.

Paying down technical debt
Paying down technical is a way of cleaning up bad design decisions and implementing an automatic test to legacy code without touching the entire legacy code base. Learn more...

Persona
A persona is an artifact that consists of a narrative relating to a desired user or customer's daily behavior patterns, using specific details, not generalities. A very popular artifact is the 'persona poster' that is usually presented in an 18 inch format with photo and text. It is quite common to see a page or two of documentation written for each persona. The goal is to bring your users to life by developing personas with real names, personalities, motivations, and often even a photo. A good persona is highly personalized. Learn more...

Persona map
A persona map is an artifact that is presented with more personas displayed and assigned tiers. This tool is used to understand user groups and their priorities. It helps focus the team on who they are actually building the system for and aids design discussions by focusing the conversations and decisions on the user instead of the team. Learn more...

Planning
Planning encompasses effort spent identifying, prioritizing, and assigning work for an entire project. This includes work scheduled within a specific iteration and work spanning multiple iterations. Planning continues until the project is complete. Learn more...

Planning Game
The planning game is a method for involving the customer (sponsor) in iterative project planning by exposing them to the identified work, capacity constraints, and time available. This forces the sponsor to prioritize work to provide the most business value in the quickest time frame. Learn more...

Plumb through
Plumb through means that stories are designed and built through the whole solution from interface to database. This keeps queues from forming between levels of architecture since the goal of the team is provide working software as expressed as business value to the user.

return to top

Q

Quality assurance (QA)
This ITS Iterative approach to QA simply revises when QA takes place. Teams address defects as soon as they are discovered instead of building in a linear fashion and resolving bugs at the end. Such conscientious coding might add work in the short term, but it ensures the team is always working with clean, functional code and vigilantly eliminating bugs. The result is a significant decrease in overall development time. Learn more...

return to top

R

Refactoring
Refactoring it that act of changing code for improved design or because requirements have changed. Learn more...

Release
Release describes the action of moving code from a non-production to a production environment.  A release can occur at the end of every iteration, or it can be the combination of several iterations of work. Risk is reduced when agile teams release as often as is sustainable. For example, one team may release quarterly while another team releases bi-weekly. Both are acceptable depending upon the throughput of the project team and the project’s timeline. However, it is recommended that releases occur at least quarterly to avoid missed opportunities to receive timely feedback that would support expedient delivery of business value. Learn more...

Requirements
Requirements define what solution the team is building, for whom the solution is being built, and why it is being built. The difference with an agile approach is that the requirements are developed and elaborated iteratively so that not all the requirements are necessary to start development. Learn more...

Root cause analysis
Root cause analysis is a process of going beyond symptoms to identify the root cause of a problem. The goal of root cause analysis is to develop a solution so that the problem does not happen again or require more attention. It is in opposition to workarounds.

return to top

S

Scripted Build
Scripted builds reduce time devoted to builds. They encourage building often. Teams will decide the frequency and approach to builds:

Show and tell
Show and tell is a face-to-face meeting with the project team and stakeholders. A show and tell is a way to involve the customer in providing regular feedback about the progress the team is making and gives the customer an idea of what they are asking to be made. This gives them an opportunity to change the direction of the project sooner than later in the process. Learn more...

Source code management
Source code management is a process that allows team members to collaborate by managing changes to different parts of the code or documentation.

Spike story
A spike story is a specific type of story card. It is used when the team is presented with unknown solutions, technology exploration, or a high-risk requirement that makes an original story difficult to estimate. The development team runs an investigation, which should be time boxed. Spike stories help mitigate architectural risk by giving team members an opportunity to try an unfamiliar solution. They are generally used for learning and estimating purposes and are not typically released to users.

Stakeholder participation
Stakeholder participation is critical both for successful planning and to the ITS Iterative software development approach. Stakeholders must be able to commit to the following:

  • Attend show and tells for each iteration
  • Participate in planning games for each iteration
  • Represent a decision-making authority regarding project goals, primary persona, and story cards selected per iteration
  • Communicate with the project manager

Stakeholder profiles
A stakeholder profile is a description that characterizes each stakeholder and explains his or her relationship to the project in order to understand the interests, concerns, and product success criteria for each stakeholder. Profiles are created after first generating a list of general stakeholder categories.

Storyboard
Storyboards graphically organize a series of functions derived from user stories, mockups, use cases, and the like. They are displayed in sequence to assist in visualizing the chronological interactions between users and systems. The team places ideas on storyboards and then arranges them on the wall. This process of visual thinking and planning stimulates group brainstorming, which fosters more ideas and generates group consensus.

Story card
Story cards are the lowest level of a work breakdown structure. Story cards are written so that the work is described from the perspective of business value and can be tested, assigned, and estimated. Learn more...

Story card walkthrough
The story card walkthrough (also referred to as domain walkthrough) is a meeting between the developer(s) and the stakeholder who best represents the story. The stakeholder provides an overview of what is to be designed or developed and explains the requirements. This should also include information that is related to the story but not necessarily part of its implementation. The developer(s) should review all pertinent documentation associated with the story before the meeting. At the end of the meeting the developer(s) should have a complete understanding of exactly what is desired functionality for the story, and what the expected results are.

return to top

T

Technical debt (see also Paying down technical debt)
Technical debt is code that works but is hard to change, expand, and maintain. Doing things the quick and dirty way creates technical debt, which is similar to financial debt. Like financial debt, technical debt incurs interest. Technical debt interest payments are the extra effort required on future development because of the earlier quick and dirty design choice. You can either continue paying interest or choose to pay down principal by refactoring the quick and dirty design into a better design. Although it costs to pay down the principal, you make long-term gain by reducing your future interest payments.

Test-driven development
Test-driven development (TDD) is a software development technique that relies on the repetition of a very short development cycle. TDD encourages writing a failing test for a piece of functionality before actually coding the functionality.

Test plan
It is useful to maintain a re-usable test plan throughout the project development life cycle regardless of the project management methodology employed. Story cards are the natural input to the test plan. In other words, unit tests of specific objects or features can and should be included in the story card description. These smaller unit tests can also be used as inputs to the overarching reusable test plan. The test plan will, then, reflect a change whenever a new feature or piece of functionality is introduced into or removed from the code base.

The wall
The wall is a tool used in the development process. The developer displays sheets for the current and previous two iterations on the wall with their attached features.

Thin slicing
Thin slicing is an approach of scoping that focuses efforts on complete solutions as experienced by the user. The process focuses on the main "happy" path, which should represent the bulk of users achieving their goals. This solution should be the first to development and then edge cases are addressed iteratively. Learn more...

Time boxing
Time boxing defines a task by a "not to exceed" duration instead of scope. This approach is used to mitigate risk associated with experimental or unfamiliar activities.

return to top

U

User-centered design
This approach calls for collaboration with the stakeholder and users to understand actual user goals. Design solutions focus on helping users accomplish those goals instead of detailing speculative features that may consume budget but are rarely used once deployed. Exposing users and stakeholders to the design early can help the ITS Iterative team expose design flaws and hidden opportunities before they are coded.

User design assessment
User design assessment tests are paper based user tests that help the design team test workflows and screen design with actual users before they are implemented by the development team. They help to uncover design flaws early in the development process.

User goal diagram
A user goal diagram is a tool for analyzing the various goals that are relevant to a project. It is used when there is a need to illustrate synergy or conflict among user goals, when a visual tool would help to identify relevant goals before findings are summarized and reported, or to identify priority goals for crafting a vision statement. The user goal diagram can also serve as a rudimentary prioritization tool for identifying shared goals among users/user groups and highlighting narrow goals with limited business value.

 

return to top  

V

Value stream mapping
Value stream mapping is a form of process mapping that focuses on reducing waste by indicating steps that are, by the business' view, value added, non-value added, and non-value added but necessary.

return to top

W

Workflow diagram
A workflow diagram is both a concept and a practical tool. It uses flow diagramming techniques to illustrate directed flows between processing steps. Workflow diagrams provide a means to expose waste and eliminate steps that do not deliver business value. For example, the diagram can expose excessive queuing or bottlenecks.

return to top