Scrum for Dynamics 365 training courses pre-launch

I'm proud to announce that Customery has pre-launched three Scrum for Dynamics 365 training courses.

Three training courses are available now for enrollment and will launch in the next few months:

  1. Free Guide to Scrum for Dynamics 365will launch in Sep/Oct 2017
  2. Premium Guide to Scrum for Dynamics 365will launch in Oct/Nov 2017
  3. Advanced Guide to Scrum for Dynamics 365will launch in Nov/Dec 2017

I'm launching Scrum for Dynamics 365 training courses because I really believe that all software implementations, especially all Dynamics 365 projects, should use Scrum. I've presented Scrum practices at a number of user group meetings and Microsoft conferences and I hope that online training courses allow my experience to be shared with the widest possible audience. 

You can get a sample of the course content on my Introduction to Scrum video.

A big thanks to a couple of people for help me get here: my wife for her patience and grace, my kids for "helping" with all the LEGO building and photography, TechSmith for the free copy of Camtasia they provide to Microsoft MVPs, all my team members at Increase CRM, Customery, Slalom and KPMG who helped me refine my agile practices, and all my Microsoft Dynamics clients along the way.

As I finalise the course content, please let me know if there are any specific topics you'd like us to include. I'd love to hear your input in the comments section. And don't forget to sign-up below if you'd like to notified as soon as the Free Guide to Scrum for Dynamics 365 is launched.

Can we have a zero-point story?

I use the popular modified Fibonacci sequence to estimate stories: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 60, 100, ∞. (The 60 point story is my idea).

But what does a 0-point story look like? Can we really deliver a CRM feature with no effort? A couple of weeks ago I was facilitating a story mapping workshop for Tourism NT in Darwin, Australia. Our stakeholders, Adam and Angus, suggested a couple of  simple stories:

  1. Add a contact
  2. Sync contacts with Outlook
  3. Add a note to a contact

These are all standard CRM features. Does that mean that they are 0-point stories that require no effort by the CRM team to implement them? First of all, I had to uncover a little of the detail behind each story:

  1. Add a contact. This was the first time we had discussed the contact entity so I anticipated some effort to customise the entity: remove unnecessary fields from the form, adjust the columns displayed in the system views and configure the duplicate detection rules. Adam and Angus agreed that they'd probably have some acceptance criteria for this story later. Where there's customisation effort there's an estimate, so this one isn't a zero-point story.
  2. Sync contacts with Outlook. Tourism NT's IT department would be configuring server-side sync or CRM for Outlook so there wouldn't be any work for the CRM team to do. But we agreed that the CRM team would probably have to work with IT to test the feature and include a section for it in the CRM user guide. Where there's test and documentation effort there's an estimate, so this one isn't a zero-point story either.
  3. Add a note to a contact. When I discussed this one with Adam and Angus they just wanted a simple feature so that any user could add a note to a contact that could be seen by other users. Each note should be automatically stamped with the author's name and the date/time the note was created. A 30-second demo of the standard notes feature was all it took to agree that the standard feature was sufficient. We agreed we wouldn't even need to test or document this feature and the standard security roles all include sufficient privileges for working with notes. So is it a zero-point story when there is no effort to estimate?

Is it a zero-point story when there is no effort to estimate?

I'm in two minds about zero-point stories.

Sometimes I find it useful to track a zero-point story so that our product backlog represents all the features we've been asked to deliver, even if some of them are free.

But there are thousands of standard CRM features that we don't ever customise and just expect to work. If we wrote an index card for all those standard features, zero-point stories our project room would be a fire hazard.

So I rarely recommend tracking zero-point stories.

Adam and Angus trashed the sticky-note for the 'Add a note to a contact' story and we moved on.

I'd love to get your feedback in the comments. Have you found it useful to track zero-point stories? Or do you rip up the stories that describe standard CRM features and move on to other more complex and valuable stories?

Documentation for CRM Projects using Scrum

You might have heard that the beards who devised the Agile Manifesto banned comprehensive documentation. But their principle is: they appreciate comprehensive documentation but they prefer working software. And I do too. But I really like good system documentation (almost as much as I love working CRM software). Have you ever been asked to support or extend working software with no documentation? I have. I hate having to do that. I associate my best agile CRM projects with great documentation. And some of the worst CRM projects I've had to turn around had terrible documentation.

Approaches to writing CRM system documentation

I've used three approaches to writing great documentation in an agile project:

  1. Wait until a 'hardening sprint' or some other time to produce system documentation.
  2. Encourage the product owner to prioritise documentation chores in the product backlog throughout the project.
  3. Include documentation in the project's definition of done.

Including documentation in the definition of done has worked better on my projects and it’s a technical practice that I recommend to my clients. I encourage you to try it too.

System documentation I recommend

What documentation should a story have before it’s declared done? Every project’s definition of done needs to be agreed between you and your product owner. Velocity is lower when there’s lots of documentation to produce, but appropriate documentation can improve the overall quality of your product.

I like to ensure there is a:

  1. User Guide updated with each new feature so that users can learn the system
  2. Test Case for each new feature so users and testers can validate the feature
  3. Design Statement so that everyone knows what customisations have been performed on the system

Design statements rather than design specifications

I recommend design statements rather than specifications. Don't document what you intend to build in a design specification. Instead document what you have built in a design statement. Better yet, jot down why you did it too. Design specifications attempt to predict how the solution will be implemented but they are often inaccurate, ambiguous, incomplete, and they rarely get updated after the customisations have been performed. I've seen design specifications describe entities whose names are different in production, security roles that don't exist and entire integrations that were never built.

A design statement describes how the solution actually works in its current state. I can produce most of the details for my design statement in 10 minutes using Snapshot! for Dynamics CRM. I can run Snapshot! at the end of every sprint so that we always have an accurate, complete, clear and up-to-date record of the system. I can even compare the design statement from two separate sprints to see exactly what’s changed over time.

Do I ever write design specifications? Sure, sometimes when our enterprise architect group or some other policy wonk is holding a gun to my head. I’ll outline my intended CRM system design but I’ll focus on the standards they are looking for: security, interoperability, and supportability.