Scrum Dynamics 29 - Done with the PowerApps Solution Checker

Can you use a definition of done for a sprint?

In Scrum Dynamics 29, I outline six ideas for a definition of done for a user story and three ideas for a definition of done for a sprint.

Definition of done for a user story

  1. The development is complete, and unit tested. If the story involved custom code then unit tests have been written and passed, where appropriate. But at the very least the developer has verified that the feature meets the acceptance criteria.

  2. The feature has been deployed to a test instance, and the developer has tested it to make sure it works as expected.

  3. The customization has been reviewed by another developer. If your team practices pair- or mob-programming, then it's naturally reviewing all customizations. If not then, get another developer to review your customizations. This has two benefits: the quality of your customization improves as another developer makes recommendations for enhancing it. Even just explaining how your feature works to someone else can help you find improvements in your own work. Second, another developer becomes familiar with your feature so that there are always at least two people familiar with how every feature works.

  4. It's been documented. Documentation criteria vary widely from team to team. Some of my teams document the feature's design in a wiki page. Others have written a release note so that business stakeholders understand the impact of new or enhanced feature. Others have taken on responsibility for updating end user documentation such as user guides or training videos.

  5. It's passed all its acceptance criteria. This step usually involves the feature undergoing a manual functional test in a test instance by someone who wasn't involved in the development. Ideally, this is a professional tester who's an expert at finding ways to break things, but it could also be an analyst, super user or another developer.

  6. It's been reviewed by the product owner. My teams always review the feature with the product owner well before the sprint review. We might even do it twice: once just after development is complete to get early feedback then we make a few changes and review it again after it's been tested.

Definition of done for a sprint

According to the Scrum Guide, the definition of done helps us agree on when a product backlog item is complete. A sprint, on the other hand, is a time-boxed event so it's done when the time is up.

But my teams have found it useful to have a definition of done for a sprint too.

  1. We run the PowerApps Solution Checker on our development solution at the end of every sprint. The PowerApps Solution Checker recently became generally available. This means it should be available for all CDS for Apps administrators. You run it against a solution, and you'll receive a report highlighting any issues that might exist in your solution. It checks against hundreds of best practices so that you can improve the performance, maintainability, extensibility or upgradability of your customisations. Occasionally, it reports false negatives, but the quality of the rule set is improving all the time.

  2. We compile our solution documentation. I've already mentioned our definition of done for each item and our documentation criteria. We also have a documentation criterion in our definition of done for the sprint, and that's to compile our as-built solution customisations into a document. This includes all the entities, fields, relationships, forms, views, and other solution components such as charts, workflows, security roles, and system settings. There's the Metadata Document Generator in the XrmToolBox, which is a free tool. But I prefer Snapshot for Dynamics 365 from XRM Coaches.

  3. The product increment is available to the users. You might be releasing a solution into production at the end of each sprint. That's definitely something to aspire to. In my current project, the product increment is shipped into QA once or twice a day during the sprint, and then into lots of additional non-production sandboxes at the end of each sprint.

What definition of done do you use for your user stories? Do you use a definition of done for sprints or releases? I'd love to know in the comments.

Links mentioned in the show