The build cycle within a milestone focuses on executing the development tasks associated with achieving the scope outlined for this milestone. This commonly equates to using K2 tooling to design workflows, forms, SmartObjects, etc., as well as non-K2 tools such as Visual Studio, SharePoint and SQL Server to design additional elements within the solution.

Common roles that participate within this phase are outlined below.

Project manager
Ensures that tasks for this build cycle are tracking to the work breakdown for the targeted milestone.
Solution architect
Responsible for technical oversight on all of the various component developers and ensures they are tracking to design. Also leads integration testing and deployment planning.
Business analyst
Available to clarify any business/functional questions that come out of the build team.
Workflow developer
Focuses on K2 workflow/process development.
UI developer
Develops solution user experience (forms/reports) with appropriate forms design tool (e.g., K2’s SmartForms).
.NET developer
If needed, handles code-based extensions and/or integrations.
SharePoint developer
If needed, creates any SharePoint artifacts (lists, libraries, sites, branding, content types).
Database architect
If needed, creates the application/solution database (typically in SQL Server).

It is a general software development best practice to ensure that all development artifacts are protected from inadvertent loss or editing. Standard source control conventions recommend the usage of a source code control system such as Microsoft’s Team Foundation Server (TFS). You’ll find guidance for leveraging K2 and source code control in this documentation.

In addition to building the components needed by each milestone, the implementation team is responsible for performing developer unit and integration testing. Unit testing requires the developer to test the components s/he creates. Integration testing focuses on confirming that all the various components from the team are deployable and functioning as a unit. Once implementation team-based testing is completed, this milestone can be promoted to the more formal test cycle.

Below outlines available supporting content for this section:

This document provides guidance on how source code control can be leveraged for K2 design time artifacts.


This phase handles non-development testing tasks such as quality assurance (QA) testing and user acceptance testing (UAT).

QA testing is performed by a testing team that is not the implementation team, but is also not the end users. It is important to distinguish testers from developers in order to force a division of responsibility and separation of concern in order to achieve more through test exposure before turning a solution over to the users.

User acceptance testing is performed by key resources from the end user community and is used to validate the deliverable has met specification and usability. The change control team is tasked with moving the solution to the appropriate test environment(s).

In order to create consistent and repeatable tests, testing team(s) formulate test cases that outline the functionality and supporting execution steps needed. These test cases are granular, with a system user focus. This granularity allows a tester to know exactly what s/he needs to execute within the solution to perform each test, as well as what constitutes a pass or fail.

It is important that test plans be structured to ensure they are repeatable across versions and testers.

Each respective test cycle should be disciplined enough to capture issues as they occur during a test. These issues should be stored in a centralized location (such as Microsoft’s Team Foundation Server), or at a minimum, within a common data store like a SharePoint list. This data will be leveraged during the next review phase.

In the event a common repository for QA issue tracking is not available, a spreadsheet can be leveraged.

Common roles that participate within this phase are outlined below.

NOTE: keep in mind that exact roles can change based upon specific project needs. Additionally, it is common for individual people to be responsible for more than one role.

Test lead
Individual responsible for constructing test cases and organizing a structured test plan and feedback capture across the testing team.
Individual(s) tasked with performing the individual test cases and gathering feedback.
Change control/operations
Individual(s) responsible for deploying the solution into new environments. In some organizations, this is a team completely independent from the implementation/development team.
Implementation lead
The lead from the implementation that is on hand to assist with general solution questions during the test cycle(s). This individual can leverage other implementation team members on an as-needed basis.

Below outlines available supporting content for this section:

This document provides an example on how to formulate a test plan.
This spreadsheet can be used as an example for QA issue tracking in the event a common repository such as TFS is not available.


Upon completion of a test cycle, the test lead will work with the project manager and implementation lead to review all items and determine the categorization, severity and priority of each individual item.

  • Categorization: determines if this is a bug or enhancement request
  • Severity: assesses the impact on operations; typically as:
    • Low: cosmetic issue or no significant impact on operations
    • Medium: impacts business in a way that warrants near-term attention
    • High: affects operations in a critical way, either through in ability to operate correctly (in the event of a bug) or potentially provides such potential improvement to operations (in the case of an enhancement request)
  • Priority: outlines the order in which items should potentially be addressed

The ability to address feedback items need to be factored into milestone and versioning planning.

Generally, medium- and high-priority bugs are deemed necessary to be resolved before closing out a milestone. Items that are enhancement requests or scope changes are factored into a new milestone, and then versions are re-assessed. Once the milestone and version roadmap is agreed upon, the project plan is updated to reflect the current thinking.

It is extremely important to have a structured review and change management process in order to avoid confusion around builds and releases and to keep costs under control. Failure to appropriately document, review and resolve the feedback and resulting changes can have significant impact on project timelines and costs.

Common roles that participate within this phase are outlined below.

Test lead
Individual responsible for constructing test cases and organizing a structured test plan and feedback capture across the testing team.
Project manager
Responsible for driving the review phase to determine new milestones and versions roadmap and updating project plan accordingly.
Implementation lead
Assists with general solution questions and impact assessments. S/he can leverage other implementation team members on an as-needed basis.

Initial Discovery

This phase focuses on understanding the high level goals, needs and timelines for the potential project. This is typically a one-to-four hour meeting in which the key stakeholders of the solution, such as business subject matter experts (SMEs), technical leads and/or project manager(s) have a discovery conversation with the leads from the potential implementation team (referred to as business architect and technical architect).

Solution Analysis and Planning

The solution analysis and planning phase is the entry point into solution functional scoping and project planning. The goals of this phase are to identify project critical success factors, as well as discover initial functional scope/business requirements and technical drivers and integrations. This phase is typically lead by the business architect and the technical architects leveraged during the initial discovery phase.

Elaboration and Design

The elaboration and design phase expands upon the previous phases by delving deeper into identifying and documenting the business and technical requirements. The goal of the phase is to derive a target solution architecture, technical design and implementation plan. This phase has a typical duration of two-to-six weeks depending on the size of the project.

Roll Out

The roll out phase occurs when a version is deployed to the production environment and becomes operational within the business unit. Learn how to coordinate a roll out across multiple stakeholder groups.