Continuing with Spikes
In my last post I described my version “spikes”, of one of the more useful techniques my technical teams have to remove ambiguity before committing to work. The last topic I addressed was the creation of a one-pager—a short document used to gather the results of the spike and provide long-term documentation.
When working with teams that have not previously created spikes they often ask me what a one-pager should look like. So in this follow up post, I’ll start off by providing an example, and then conclude with some final thoughts on the use of spikes.
Example One-Pager
Over the years a number of my teams have looked into adding a rich text editor to our UI functionality. Below I provide an (imperfect) example of a one-pager for an investigation into possible rich text editor choices. Note that the requirements are so basic, and existing rich text editors are so powerful, that many reasonable choices exist in this case. Not all spikes, unfortunately, are quite so easy.
Take a look at this example, and think about what you might add or change. As with any useful process, you need to tailor the usage of spikes to fit your teams.
A side note: As I was writing this blog I discovered that the Quill editor was created by former Salesforce teammates, Jason Chen and Byron Milligan!
Spike: Rich Text Editor
Requirements
Note that these requirements likely come directly from the spike story.
We need to find a simple rich text editor that we can easily integrate into our Vue front end component suite in a couple places. We would prefer to use an open source (free) editor that can support bold, italic, different font sizes, and numbered lists. Other editing features are nice, but not required. We need basic support for skinning. While the storage format does not need to be plain text, we need to be able to search it for keywords.
This spike should look at a few alternatives and make a suggestion, along with the stories required to implement it. The team will discuss, before we implement the suggested editor.
Choices
There are many rich text editors available. I utilized this site to compare some of the most popular.
- Tiny Editor is one of the most long-standing and well-known implementations. It does everything we need and far more. The community edition is free to use.
- CKEditor is another long-lived implementation that meets our needs. Note that only the “free lancer and small project“ version is free.
- Quill brands itself as an open source, API driven, rich text editor. It also supports iOS and mobile—not a requirement for us, but a nice-to-have. During my investigations, I stumbled onto a Vue component that wraps Quill.
Editor Selection
All of the editors are well-known and possess good, ongoing support. They all meet our basic editor requirements, can work with Vue, and can be skinned through CSS. They all should be fairly easy to implement and produce searchable output formats.
CKEditor seems like it will have a low, but non-zero licensing fee.
CKEditor and Tiny Editor have been around 15+ years, and they may have some legacy cruft, based upon some reviews. However, it is not clear that this fact would affect our simple use cases.
Quill has a getText() function for finding text strings. Tiny Editor has a search and replace plugin. CKEditor has a Text Match add on.
I did not see any data on the sizes of the various editors, but my searches did not reveal many concerns about any potential impact on page load speeds.
I did not attempt to implement any of the choices. However, if anyone has reason to be concerned, we can discuss implementing a prototype. They all look reasonably easy to implement, although each has its particularly quirks.
I get the impression that the Quill model is a little more modern and extensible, so I will recommend that we use this editor. Quill also seems to be gaining better traction based upon npmtrends.
Stories
Note that the stories could be included as part of the one-pager, or could go directly into your backlog-tracking tool (i.e. Jira).
Story: Implement rich text editor
Add the editor code as a Vue component, and hook up the output to our existing text storage.
All the examples look pretty straight forward, but we will need to implement some new tests.
Note that we cannot use the rich text output in our existing text boxes, or print it out directly (although it may be possible to get the unformatted text if we ever desire to do so). We may want to break this story up if we think of additional implementation complexity.
Estimate suggestion: 5 to 7 points
Story: Customize the editor look
Basic customization to make the editor look like our other components. This should be relatively easy as we have good reference implementations in our existing component sets.
Estimate suggestion: 3 points
Story: Implement search functionality
Extend our existing search functionality to the new component. Since we only care if we find any instances of a string (we don’t search for multiple instances or search and replace), this should be quite simple.
Estimate suggestion: 2 points
Gaining Traction with Spikes
As with any technique, some coaching is likely necessary before engineering and product management teams both understand the need for spikes, and consistently create good ones.
Sprint kick-off meetings, during which teams get together to story point and accept work, are when spikes should be added to the backlog. Spiking should be suggested when the team seems unclear about the effort level of a technical challenge. (Often this is indicated when they specify a high number of points for a story because they don’t know its true difficulty.) Teams may struggle to define and execute their first couple of spikes. Let them know that this is normal and guide them along their way.
Retrospective meetings are a great opportunity to point out the need for spikes (retroactively). During a retrospective, teams can identify the stories that would have been clearer, or better resolved, if a little research had preceded them. Once a team begins utilizing spikes, retrospectives can be used to talk about tweaking the process in order to ensure that the spikes provide the necessary information.
Who Needs Clarity
Teams may initially resist spikes because they are “additional work” or “just documentation”. Some engineers dislike spikes because they feel that the solution will become clear once they begin coding. Indeed, both engineering and product management may initially object to spike stories as taking time away from product development.
However, this is backward thinking: If a team does not know how to resolve a technical challenge it will have to figure it out one way or another. Far better to take a simple, but structured, approach wherein the results can be discussed and the effort level exposed, rather than to hack away in the dark. It is not unusual for work to be pared back, reprioritized, or even removed when a spike reveals the true extent of the challenge. A good spike can provide exactly the sort of clarity that teams need to reliably deliver on their commitments.