Business Updates

We started a few pilots this month with prospective customers which has been great. Seeing more people use it in anger, especially folks who don’t have our background and context, has been fascinating. We also got some good performance data — more on that in a minute.

Starting Stories?

It turns out that mostly what people do when you automatically move a story on starting is… move it back to where it was before. This surprised us, because this is what Pivotal Tracker used to do, but we’ve turned that feature off. We might revisit in the future, but for it seems like people who use StoryTime want to see very clearly when stories are being skipped over.

Plan releases by scope or by date

The big feature this month is date markers. The existing marker is now called a “scope marker.”

Scope markers stay where you put them in the main board, and display a projected date, when StoryTime thinks you’ll arrive at them. If that date isn’t right, you can move stories above them down.

Date markers, on the other hand, “float” in the backlog based on the date you select. When you move them from drafts into the main board, they’ll automatically move to the position StoryTime expects to arrive at that date, and then they’ll (mostly) stay there.

We built this feature mostly for ourselves, because we found ourselves moving our markers around a lot to approximate a fixed date, but we’re looking forward to showing it to folks and finding out what ya’ll do with it.

The App is Faster Now

All database transactions are about 40ms faster, because we moved the database from GCP’s us-central-1 region (which is not where the app is hosted) to AWS’s us-west-2 region (which is where the app is hosted.) Behold, both the most magnificent and the most mortifying graph of my software career:

Why was it there in the first place? A mix of my preference for AWS over GCP, Gigalixir’s defaults at the time I first deployed the application, and not fully understanding the performance implications of putting the app that far away from its database.

It became clear this month that something was wrong, because we started seeing transactions get dropped from the Postgres queue when 8 or 9 clients loaded rooms simultaneously. While loading a room is a relatively expensive operation (and we streamlined it somewhat — removed some redundant transactions) it’s not that expensive. “10 simultaneous users” just didn’t seem like enough traffic to start causing database problems.

Anyway! The app is much snappier now. Still more work to be done to get it feeling really good, especially in Australia.

Other Changes this Month

• Hide/show recently accepted stories, to make it easier to understand rooms where a lot of work is being completed

• Change draft numbering from 1, 2, 3 to d1, d2, d3 to make it easier to discuss drafts in planning meetings

• Fetch the top started story via the agent API, to allow agents to load the current story when the start a session. This doesn’t distinguish between stories started by different users so it only works right now for single-user rooms.

• Create draft stories via the agent API

• Fixed a bug where titles wouldn’t get updated correctly by cut/paste operations

Planned for Next Month

• Finish date markers

• Move multiple stories with multi-select

• Reduce the interruption caused by deploying the application

• A collapse/expand control for drafts, so we can use that space for other elements sometimes

• A filter/search function that will allow you to view a subset of stories marked with e.g. a particular tag

• Login with a Google Account

• At least the beginning of “crewing” — being able to see who is working in which rooms and on which stories

I will be a little bit surprised if we get all of that done next month— I think StoryTime is being a little bit optimistic in its predictions— but we have been cranking out stories recently so hopefully I will be pleasantly surprised.

Until next time,

Nat