Part of the Process

BOOK REVIEW: Fifty quick ideas to improve your user stories by Gojko Adzic and David Evans It has taken a while since my last book review to get the time to do much reading with moving. But here is my round up of "Fifty quick ideas to improve your user stories" by Gojko Adzic and David Evans Formats : Paperback, ePub, Mobi, PDF Where can I get it? From Leanpub , Amazon or any good bookshop.   Who is it for? Anyone involved in a software development project working in an iterative manner. As long as they understand some of the basics around user stories, e.g. they know what INVEST stands for. What's it about? As the title suggests "how to improve user stories", but it is a bit more than that. It covers the whole process including planning and iterative delivery activities. What's the book like? Each double page spread follows a similar style starting with an introduction to a new tip. Often illustrated with an anecdote fro...

In this post, I'd like to make a short plea for better product documentation. One of the entry points to the Cronofy API documentation has an explicit link "for Product Managers". This link takes you to their use cases page. Over the past few years, I have looked at plenty of API documentation. From PDFs to the current trend of a GitHub repository and wiki. This was striking in how unusual it was. But if your product is an API then why should it be? In the technology service industry should we go further? Should there also be a "for testers" link? This could be like the Cronofy Product Managers link. It could reuse existing information but highlight and target them for a specific audience. For example, take the developer sections about rate limits and validation. Then add testing tips about your API for integration testing. Stripe has good developer documentation . Yet you have to scroll down a couple of pages of information before reaching the words "...

Photo by Sebastiaan ter Burg So having a good roadmap with themes it is now important to get the work delivered somehow. Unless the developers have done something similar enough before. You need some way of discovering how to chunk up the work. What you call this doesn't really matter, but I have used the agile term "spike".  According to a comment in the Agile dictionary , this is a rock climbing term. A spike is driven into the rock face to help support the climbers. Although it does not get us closer to the top it allows us to go faster and have a safer climb. Likewise, a development spike doesn't produce the feature faster, but it provides a foundation to move forwards. In a project kick-off meeting, I remarked about how successful the spike had been. A developer there joked that I should write a blog about it, so here it is... "challenge accepted". I have been reflecting on what I feel made the spike successful. This particular...

I am currently lucky enough to be working on a project where the developers are looking into what they can learn from academic computer science and spiking various options to explore the solution space. This got me thinking to how relatively rarely you see this, in my experience programmers tend not to read industrial journals in the same way that say civil or electrical engineers might.  One thing that I would expect to see more in agile literature are Grice's conversational maxims (Grice 1975) Maxim of Quantity: Make your contribution as informative as is required for the current purposes of the exchange. Do not make your contribution more informative than is required. Maxim of Quality: Do not say what you believe to be false. Do not say that for which you lack adequate evidence. Maxim of Relation: Be relevant. Maxim of Manner: Avoid obscurity of expression. Avoid ambiguity. Be brief (avoid unnecessary prolixity). Be orderly. For me the...

It's been a while since I've written up a work orientated blog post. At the moment two (relatively ;) exciting things are happening. One is the introduction of JIRA, Confluence and GreenHopper and the other is working on a series of projects to upgrade customers, getting them onto the latest version of our company's main product. I'm working along the lines of getting three categories of info in JIRA/confluence: 1.        Jira work items 2.        Confluence (upgrade) project wiki 3.        Confluence wiki page per customer The first item should be quite straight forward and contains information needed for the life time of that work and a point in time record of the system (i.e. what was the state of play when the JIRA was raised/worked on?). For example, a story on a feature has the handover documentation for the original implementation attached as word files, so the current st...