Problem

As a practitioner of good source control, you and your team have decided to make all of your git commits atomic within your projects. That is, every commit has a green test suite, and you prefer small, incremental commits to large, monolithic ones. Keeping commits small and atomic has tons of benefits, from more consistent continuous integration results, to better team cohesion (have you ever gotten upset with another team member for committing red?). But in practice, keeping all of your commits atomic can present some challenges.

After doing a bunch of work, making incremental, atomic commits along the way, it's time to push your work up. However, when you run git pull --rebase, you find that another team member has made changes since you last pushed. Your commits are now sitting on top of a different git history. Are all of your commits still atomic? Short of checking out every single commit and running the suite, how can you be certain that every commit is atomic? What a pain! I don't want to check out every commit by hand.

Being a consultancy, we at Hashrocket are frequently presented with the challenge of accurately setting budgetary expectations for our clients. Traditionally this has been handled by capturing requirements via story-cards and then estimating the complexity and risk of those stories using a point-based scale. We would then sum the total points for the project and divide that by our historic average velocity to project the amount of time we think it might take to complete the project. Over time we have learned how absolutely flawed this system is.

Daniel and I flew out to Las Vegas last week to attend Future Insights Live, and proceeded to violate the city motto by bringing back some knowledge, just for you. Here we go:

A question we often get at Hashrocket is, "story carding create, read, update and delete pages is easy but how do you story card an API without talking about implementation?" and the answer is that you can story card an API as interactions. You might end up describing more implementation or technical details and that is ok.

I work on story cards for a lot of projects each year at Hashrocket and also see a lot of backlogs maintained by clients and open source projects. A notable difference that I find between healthy projects and unhealthy projects is the way in which stories are written. I am purposefully leaving out any discussion about managing and grouping stories at a feature set level but will cover that in a future post.