Build is an exciting phase of the project, where the application becomes a reality. Like the Discover and Prepare phases, Build is highly collaborative, where the business, IT and test teams work together during each sprint. The best practice approach is to have a repeatable process that promotes agility which supports Pega’s ‘Build for Change’ philosophy.

At Pega, we use Scrum to deliver in Sprints (1 to 3 weeks). During each sprint, user stories are configured and tested to meet the ‘Definition of Done’. Testing includes unit testing, business testing (UAT) and integration testing. The business representatives on the scrum team should have regular opportunities to provide feedback during playbacks. Don’t wait until the end of the sprint to provide feedback and gain acceptance. At the end of each Sprint, the extended team can see what the team have built and tested (‘Done’) during the Sprint Review.

A first release will typically include three or more sprints. Testing occurs during each sprint. For a first or major release, as we approach the final sprint, we will perform hardening test activities; you will conduct performance, security and end to end UAT testing to ‘harden’ the application before it goes live. Hardening can happen in parallel to sprints, or within a sprint - this can depend on the nature and timing of penetration / performance testing, which often involve external teams. If it’s not your first release, or a major release, you should be challenging yourself to deliver new features to Production after every sprint, so you continuously add value to your application.

Each sprint will start with Sprint Planning on day 1 of your sprint. This requires some preparation to ensure that you have a list of user stories in your Product Backlog that meet your Definition of Ready (sized and ready to be configured). These will have been prioritized by your Product Owner. You will also have calculated your team’s sprint capacity. During Sprint Planning the Scrum team come together to determine the sprint goals (typically no more than five) and how many user stories you can deliver in the sprint; this is called your Sprint Backlog.

During Sprint Planning the team will review the already sized stories and understand the dependencies for build activities. The team may decide that the sizing needs to be adjusted; each story should be small enough to be delivered in one sprint. If a story is too large, it should be split into smaller user stories if possible. Each story is sized using story points. The total number of story points should be less than the team’s capacity. During the first sprint, the capacity will be an estimate. Estimation will improve from sprint to sprint as the team learns more about themselves. Outputs from sprint planning include updating your project management tool with the sprint backlog so you can measure your sprint burndown, and a visual story wall the team can use to track progress. On day 1, your sprint burndown will be at its highest, equaling the total of all user story points.

Now it’s time to build and test. Your build team will know which best practices and tools to use during build. It’s important to have close collaboration during a sprint. The team will get together during the daily stand-up and keep the story wall up to date. Once a user story has been built and unit tested, it will be delivered into a test environment, ready for testing and business feedback. User stories should be released for testing throughout the sprint rather than at the end, so you can complete user stories to the Definition of Done gradually throughout the sprint rather than at the end, which would otherwise put too much pressure on testing. Once a user story meets the Definition of Done, your burndown can be reduced. Early feedback is also important; don’t be afraid to share a user story mid-build through playback sessions and ‘Lean User Testing’ sessions. During a playback the team ensures alignment to their vision/concept. During ‘Lean User Testing’, five users outside the team will validate concepts, designs and verify desirability and adoptability. Both can be invaluable for avoiding late feedback that could have been addressed earlier.

At the end of the sprint, all user stories that meet the Definition of Done should be shown to the extended team during the Sprint Review. The team should also get together to learn about what went well and what can be improved during the next sprint in a retrospective.

The Scrum Master will guide the team through all these ceremonies and ensure that the project management tool you are using is up to date.

During each sprint, you will also prepare user stories for future sprints using Directly Capture Objectives (DCO). Each user story should be reviewed together by a business representative, developer, experience designers and test team member to ensure everyone has a common understanding. A sprint elaboration plan is a useful tool to help the team prepare for DCO and user story review sessions in advance. The Product Owner will continuously review the Product Backlog, as priorities and size of user stories may change.

What happens next? This typically depends on your project. Usually, you would repeat this process during the next sprint, knowing that you have an up to date Product Backlog and user stories ready to go. You will action some of the lessons you learned from your retrospective. If your next sprint is your last sprint before your first release or a large release, you will enter a hardening sprint. If you are part of a mature project during a second or third release, you may be regularly deploying new features to staging, then production.

For more detailed insights, refer to the Configure and Test sections of our content on Pega Community and review the related content links below provide methods and tools to help you.