Length of a Sprint

You can choose whichever sprint length best suits your project and business. You want to find a happy medium between a sprint that is short enough to course-correct if needed, but not so short that you are spending all of your time in planning meetings. The length of the sprint doesn't really matter—what matters most is that once you set your sprint duration, you need to stick to it. I prefer a two-week sprint because it holds people more accountable to get their work done in a shorter period, and it allows you to see if you are off-track quickly. We recommend two-week sprints on our projects, and that's what we use with our product development team internally. We use a four-week sprint with our IT group because we have a small number of people there and we do mini-releases every four weeks, so it corresponds well with our activity level. Each situation can be different, but I recommend two-week sprints on ERP or CRM projects.

Start and End of a Sprint

We have spent more time than I'd like to admit debating what day of the week is the best day to start a sprint. Often, I see sprints starting on a Monday and ending on a Friday. That works, but it has the downside of having to start your week off with your planning meetings and keeping you late on Fridays to do your review meetings. It also doesn't provide people the weekend to catch up if they are running behind on a project. On our product development team, we switched to running our sprints from Wednesdays to Tuesdays, and that has worked well. On the last weekend, if you are behind on your task, you can put in a few hours to get it done (in the purest sense of agile, you should have the work so well planned out that you don't have to have anyone work on a weekend, but the reality is often different). Then the sprint meetings are in the middle of the week when there is less vacation time, so attendance is typically higher.

Another consideration is the timing of your releases. As in the previous example with our IT team, we do a release each month, so we build our sprint to be two weeks of development, one week of testing, and one week of release prep and preparation for the next sprint. We do a release on the weekends every four weeks, so it works to have a Monday through Friday sprint cycle.

Delivering Value in a Sprint

Sprints allow you to deliver value in short amounts of time, so everyone has visibility to progress, but they also provide an opportunity to adjust if needed. Operating in sprints allows you to shorten the feedback loop and quickly identify if a task is going to greatly exceed the allocated time. It also allows you to pull in new requirements quickly if you need to move the dates of your delivery around. In the world before sprints, resources could go into a cave and work, and work, and work on one single delivery and never have to report on progress to another member of the project team. This led to some bad surprises when it was finally time to check in. If they did something wrong or took a poor approach, it was too late to change it. Shortening the feedback loop encourages not only accountability, but transparency and visibility to the team and other stakeholders.

At the end of Chapter 5, “Organizing Your Team for Success and Project Governance,” I mentioned this concept of the earned value curve, which shows the value of the work done versus the time spent on the work. Without sprints, you wouldn't have the yardsticks to show you how much was done and how much value was created from that work.

Project Backlog

The project backlog is the list of all work that has been requested to be completed on this project. This includes work that you would classify as “must have,” as well as work best considered as “nice to have.” All of the work that anyone can dream up should be in the project backlog, but those “nice to have” items would be prioritized down to the bottom of the list. For this ERP or CRM project, the scope of activities required to deliver on your success criteria should be logged in the project backlog. As nice as it would be, the project backlog is not a static list; it will evolve over the project, and you should budget for unexpected items as you lay out your schedule. For example, you can never accurately predict how many bugs you'll have and when they need to be fixed. As a rule, we typically budget 35 percent of the customization effort for bugs and rework on design. If you have 100 hours of development on the project, you should build in 35 hours for rework and bugs. When planning your schedule, you can allocate time for this in one of two ways:

• You can put placeholders for design, development, testing, training, and bugs/rework into your project backlog.
• You can decrease the available time for other tasks to reserve time for bugs.

As you learn more about the project, you can remove the placeholders or expand the available time when you have a more accurate prediction.

Sprint Backlog

The sprint backlog is the amount of work to be done within this sprint. Let's use a two-week sprint for this illustration. You will assign backlog items to be done within that sprint and assign it to one person who can see what tasks need to be accomplished during that two-week period.

The project manager who is assigning the work will try to allocate the right amount of work to the resources during that sprint so that it can be accomplished. This provides a measure of accountability to the resource if the work is appropriately allocated. During the sprint planning meeting, you want to ask each resource if they can get their work done during that sprint. Sometimes, you have to push certain team members, while others you have to stop from over-committing.

When you have a task that needs to be completed during that sprint, you adjust the sprint or iteration value on the task so that it's clear when it is scheduled to be done.

At the end of each sprint, you will undoubtedly have something that didn't get done as scheduled. When that happens, you ask the person to update the remaining hours on the task so that you can allocate that work to the forthcoming sprint or determine if someone else has the capacity to pick up the remaining work. On each task, you will have an original estimate and a remaining work value. If the task was slated to take 40 hours and the resource has 4 hours left, you allocate 4 hours of work to the subsequent sprint so the resource can get that done.

Allocating Work to Team Members

How many hours of work should you allocate to each resource during a sprint? If we assume a two-week sprint, that gives you 80 hours to assign. You can navigate this in two ways: either you can pad the estimates to allow for email time, bathroom breaks, random questions from neighbors, and so on, or you can assign them a smaller number of hours to allocate for those realities. If you both pad estimates and give them less than 80 hours of work, you may be not be getting as much done as you need. I recommend having accurate estimates and assigning 35 hours a week (7 hours a day) of work to give some time for other distractions. I wouldn't recommend allocating 80 hours of work unless you expect them to work overtime.

Your team members will take vacations and sometimes be out of the office (or pulled away) unexpectedly. First, you want to ask them to put their vacation days into the DevOps calendar so that you can reduce their task load to reflect that time off. If someone is off for a week, you can only assign them 35 hours of work for that sprint if you expect to be accurate. Emergencies happen, and sometimes a resource will be pulled off scheduled work to handle one. If that happens and it's project-related, add that task or event to the schedule so that you know it happened. You'll ultimately have to move their scheduled task to the next sprint. For a non-project-related task, you will need to reduce their availability to reflect that time away.

Sprint Success Rate

I'd love to say you should hit 100 percent of what you schedule each sprint, but that doesn't typically happen, and it becomes an unrealistic goal. Often a task from another sprint or something that wasn't scheduled ends up getting completed in the sprint, so there is the potential for bonus work to be completed. Overall, a good target is 95 percent of the work to be completed in a given sprint. Since you're not expecting 100 percent to be completed within any particular sprint, you shouldn't build your project schedule assuming 100 percent of your sprint work is done when you expect. I would plan for 85–90 percent of what you need to get done in each sprint if I'm laying out the initial schedule.

Sprint Planning

The sprint planning meeting is held either right before the start of the sprint or on the morning of the start of the new sprint. This meeting is led by the project manager, and the purpose of the meeting is to allocate work for the upcoming sprint. The project manager will first look at the resource allocation during that sprint—are any people taking vacation when they had been expected to do lots of work?

When it comes to work planning, the meeting begins by reviewing what work didn't get completed from the previous sprint and allocating the remaining hours into the new sprint, assuming that it still needs to get done. Next, the project manager will move to the items expected to be scheduled during this sprint to affirm that they still make sense and that they should still be scheduled. Then the project manager will look at new requests that are timely and find room to get them done during that sprint if they need to be done. Lastly, the project manager will look at how much work has been allocated to each person and try to validate with them if it's reasonable for it to be completed in the next two weeks.

The project owner needs to be at this meeting to advocate for key work that needs to be done during this sprint. The project owner may have to push the team to work extra hours during a given sprint if something is particularly time-dependent; but they also know that they can't do that every sprint without negatively affecting the morale of their project resources.

This doesn't necessarily need to be a 60-minute meeting. One way that I've seen work well is for the project manager to reach out to each resource on the team to work with them on their upcoming work. Often, the resources know what they need to work on next, and they can do most of the sprint planning work on their own.

After each sprint planning session, the project manager should send out a message to the project team indicating the key project goals to be accomplished during the upcoming sprint.

Sprint Review

The sprint review meeting should happen at the end of each sprint. My preference is to have it occur just before the sprint planning session so that you understand how much work was completed in the previous sprint before you allocate work into the next sprint. I've seen situations where teams skip the sprint review meeting altogether, and the project manager does the sprint review and follows up with people directly if there were tasks that didn't get done when expected.

Ultimately you want to be able to measure your success during that two-week period and identify if any resources consistently can't complete their tasks during their sprints. You should generate a report showing the work output expected versus the work output achieved.

After each sprint review session, the project manager should send out a message to the project team indicating what was and wasn't completed during the previous sprint. It works best to send the sprint planning and review content out at the same time.

Sprint Retrospective

I never liked the term “post-mortem” for a meeting to review how well a project went. That sounds like a funeral. I much prefer the term “retrospective” as a way to look back and evaluate the success and failures of a project. That's the purpose of the sprint retrospective—to provide some analysis on what went well and what could go better after each sprint.

You can choose whether or not you want to invite everyone to this meeting every two weeks—it can indeed get repetitive if you have the same person underperforming each week. I think it's a good time for the project owner, engagement manager, and two project managers to reflect on what went well and what could go better. Sending a brief survey to the team members to collect any feedback is a quick way of getting reactions that can be useful to the trajectory of the project.

Stand-up Meetings

Stand-up meetings (also known as a daily scrum or huddle) are among the most valuable meetings that you can have on a project. They are often meetings that start out being run correctly but ultimately devolve into mini status reports. It's important to run these meetings correctly and stick to the formula that has proven effective here.

They are called stand-up meetings because the goal is to get everyone in a room and have them provide an update while they are, literally, standing up. They shouldn't bring their laptops to the meeting—they should come prepared to listen, focus, and then head back to their desks. In a more virtual world, they often can't be done in person, but the spirit of everyone standing up and paying attention should be honored.

The meeting should last no longer than 15 minutes and should include no more than 10 participants. The project manager should keep the meeting moving with the goal of trying to wrap up early.

Each person in the meeting answers three questions in less than one minute:

1. What have I completed since we last met?
2. What do I plan on completing by our next meeting, or what am I working on?
3. What's preventing me from reaching my goal, or what do I need help with?

A typical response should be, “Yesterday I finished up task 2345, the button for the customer portal, and today I'm working on task 2346, which allows people to update their contact information on the portal. I could use help from Bob because I don't know where to connect to the contact information in the CRM system.” That response hit on all of the high points and was delivered quickly. From there, the project manager would ask Bob, “Do you have time to help?” If so, you and Bob should set up a separate session to work through whatever information you need. You do not try to solve the technical problem in the meeting.

The project manager needs to listen closely to the updates, and if a resource is running behind on a deliverable, the project manager should specifically ask that person if they need help. If a resource was supposed to be done with their task on Tuesday, and it's now Thursday and it's not done, they either missed on the estimate of the work or they need help. As a project manager, it's your job to listen for that and help remove any barriers or roadblocks that person might have.

At the end of the meeting, the project manager can give a quick update on any meetings that are happening that day and any prep work that the team should be working on. The project manager also then asks if any blockers/dependencies are holding anyone up, so there's a chance to share that information before the meeting ends.

The stand-up meeting should happen every day on a big project. It's important to check in on project status and hold everyone accountable in order to make continuous progress. For smaller projects or projects in the Empower phase, you can move to a two- or three-day-a-week cycle. If they are run efficiently, it doesn't represent a big time commitment, and it gives everyone a chance to connect on a daily basis.

If you have more than 10 people on your project, I suggest that you break up your stand-up meetings into two or more groups. Perhaps you have all of the finance resources together in one meeting and all of the technical and development resources in another. Then the project owner and project managers can do a quick meeting afterwards to share any notes and raise any concerns for that day.

Epic

An epic is defined as a large user story that incorporates many user stories, features, and requirements. We typically associate an epic with a Process Category, such as Project to Profit. An epic essentially serves as the top of the hierarchy for a collection of work within a Process Category.

Feature

A feature is a business function or an attribute of a system. Features typically comprise multiple requirements and typically include many user stories. Features can be functional or non-functional, but they typically sit in the middle of the hierarchy with epics above them and user stories and requirements below them. We equate a feature to a Process Group and a Process, so we typically have two levels of features in the system: one at the Process Group level (for example, Managing Vendors) and one at the Process level (for instance, Creating a Vendor).

User Story

I often equate a user story to a business scenario. It outlines the physical activities that the company resource must perform in order to complete a process. User stories may contain multiple requirements and may span multiple features, but they generally sit in the hierarchy below the feature that best relates to the work being performed.

User stories typically consist of a description of the activity (in business terms and not in the way it was done in the previous software), an estimation of effort, and an acceptance test. User stories are very important for testing purposes as functional tests should relate to these business scenarios.

Requirement

A requirement is defined as a condition or capability needed by a user to solve a problem or achieve an objective. Requirements can be functional (I need to show this field on a report) or non-functional (the report must generate in less than 5 seconds) and typically come with an associated task.

Requirements can sit under a feature or a user story on the DevOps hierarchy and are important to track. When you're conducting your fit/gap analysis, you will be looking at custom requirements and the associated work to see whether this requirement will be included in the implementation project.

There is often a debate on projects as to whether all requirements should be tracked or just requirements related to a customization. For example, do you track the requirement that the create vendor screen must have a field for the vendor address? This exists in all ERP solutions, so it is typically considered a standard feature. This is a determination that should be made early in the project to avoid potential confusion.

Research Task

The following tasks make up the common place to store work. Each work item has an Original Estimate and a Remaining Work hour area, which allows you to associate the work effort to the task.

A research task is a set of hours allocated to a resource to research a potential solution. This is not the time it takes to create a design—it's the time to look into potential options for a larger problem. For example, if you need to research the different potential software vendors, you will need to set up calls with the vendors, and that would be a case where you'd want to assign a research task.

Design Task

A design task provides the necessary hours to create a functional design document or another form of a design for a customization. This customization would need to be designed and approved within this time frame, so be sure to build in a little additional time for the review with the developer, the review with the core team, and the approval by the business process owner.

Development Task

Once a design is approved, it's passed over to the developer, and the development task is where the developer allocates their time. During the development task time, the developer needs to review the design, develop the game plan, write the custom code, develop a unit test, write up how it was done, and show the customization to the functional consultant. We typically set a 4-hour time frame on the easiest of customizations because of all of the effort it takes to get it moving and reviewed.

Test Task

A test task is not to be confused with a test case or a test. A test task is typically the time required to write up a test case and do the initial testing of a customization.

Other Task

You may create other tasks for any reason you would like. Assign hours and a resource to it and do your best to describe its purpose.

Test Case

A test case is the outline of the steps required to accomplish a scenario in the software. Test cases are typically associated with user stories. If you outline the steps there to complete a task, you should create a test case to reflect those steps once you have it working in the software.

Test

A test is the act of a running a test case. A test should be run by multiple resources to validate that it is working. Ideally, you would run the test case with an automated test, and you would record the result of each run as the test activity.

Bug (Defect)

In software, a bug is a defect. If you wanted the software to show an alert saying, “Hello World” and it says, “Hello Moon,” you have a bug. Bugs are common in software development, and they should be prioritized for completion according to the priority scale outlined in the next section regarding DevOps fields.

There is a difference between a bug and a design change, but this is often not articulated on a project. Going back to my basic example, if the requirement were to give an alert that says, “Hello Moon” and the core team now wants it to say, “Hello World,” that's a design change, not a bug. A design change should generate a change request to approve the change in direction.

Risk

A risk is a potential issue—it is something the project team is worried about occurring. When you define a risk, you provide a description, your plan to avoid this risk, note any potential triggers, and your contingency plan in case it occurs. Risks should be defined at the beginning of the project and updated throughout.

Issue

An issue is something that has occurred that requires some kind of mitigation plan. An issue is not the same as a bug—it's bigger than a bug. An example of an issue may be a resource leaving the project. You now have to develop a plan to bring in a replacement resource, which may affect multiple tasks and delay the project.

Change Request

A change request activity type in DevOps is an indication that one of the tasks is a design change or outside of the original scope of the project. Change requests should be approved before you proceed with work on them as they affect the scope, schedule, and/or budget of the project.

Code and Changesets

When you make a customization in a Dynamics product, you can tie that customization back to a DevOps task and check it into the code repository. Collections of code become a changeset, and those are what make up the changes that you see when you release the latest code.

DevOps Fields

The following are the core fields that you'll find on a DevOps task and how each field should be used. Depending on the template you use, there may be many more fields. Table 6.1 outlines the core fields that you should be using.

Progress Reporting

You can report on data in DevOps in many ways, just like many ways exist to report on information in Microsoft Dynamics. Some of the more common solutions are as follows:

• Kanban Boards   These create a list of tiles within DevOps where you can see the activities in the given sprint.
• Queries   You can use this to build whatever views or grids you want to see within DevOps. You can also easily export this data to Excel. This is typically where you see views built to show Priority 1 (P1) and Priority (P2) bugs and what tasks are assigned to a given resource.
• Dashboards   You can create a dashboard to summarize the most important information at a glance inside DevOps. You can pull in charts as well as summarize query values.

Analytical Views

These are entity definitions that you can use to create reports in Power BI. This allows you to indicate which columns you want to expose so that you can connect to them in Power BI and build the visuals there that you want to see. Figure 6.2 is a mock-up of the Kanban board functionality.