I spent the day doing Scrum training with some of the teams who work on the BHF website. Everyone had different levels of experience of using Scrum and those who are currently working in Scrum approached the training in a very different way to those who aren’t. It was clear they were seeking answers to specific challenges they are facing.
For me, the interesting thing was talking about ‘Definition of Ready’, which is something I’ve not previously given much thought to. It’s obvious that a piece of work has to be ready to be worked on; clear requirements, stakeholder agreement, etc., but the idea that the more certain a thing becomes the closer it is to being ready connected with my thoughts about uncertainty and risk.
I’m reading Dr. Jeff Sutherlands book ‘Scrum: A revolutionary approach to building teams, beating deadlines and boosting productivity’.
It seems like a good opportunity to put into practice some of the techniques of Scrum to help me read the book productively.
User stories
User Stories are written in a ‘who, what, why’ format and are used to express the customer’s motivations and what they want to achieve.
Let’s write a user story: “As someone interested in learning about Scrum I want to read a book about Scrum so that I can learn and think about some of the principles and practices of Scrum.”
Now let’s a quick look at the user story to help us understand what its not saying. So, I’m a user with an interest in Scrum, not a practitioner who needs to retain expert knowledge. But I do want to be able to reflect on what I’m reading and learn from it, but not memorise it or take notes outside of the book. It mentions thinking about Scrum but not putting it into practice which helps to keep it small, distinct and contained. If the user story mentioned being able to put Scrum into practice we’d have to consider the outcomes differently.
Definition of Ready
In order to tackle the user story and start a sprint we need a definition of ready. It should be help us know if the user story is independent, negotiable, valuable, estimable, small, and testable.
We’ve got our user story, and thought a bit about what it isn’t, and it meets the INVEST criteria, so we’re ready to go.
Definition of Done
We need to know whether I’m achieving what I set out to, so we need a definition of done which we can then use a) know what we need to get done in each sprint, and b) compare with our user story to know if we’re delivering value to the customer.
Our Definition of Done: “A chapter has been read, and sentences that resonate with me, seem important, might be something I want to look back on, or ideas I want to think about have been underlined.”
Reading in Sprints
As this user only gets time to read during my commute we should set our sprint length as 15 minutes. My commute is longer than 15 minutes but with distractions and ‘reading with a pen’ 15 minutes of focused reading is achievable.
Measuring velocity
Chapters are not of equal length so there aren’t a good measure to use, even though they are mentioned in our definition of done. Perhaps we should use pages as our measure as they are of fixed length. We have to take into account not just the reading but the underlining and thinking, so let’s say that to start with a velocity of a page a minute. There are 238 pages in the book (let’s round up to 240 for ease), which equals 4 hours of reading. Divided by our 15 minute sprint length means it’ll take me 16 sprints to finish the book.
I’m on page 146 right now so this is what my burndown chart looks like:
How could we increase velocity? I could underline less, or think less about what I underline, but then would I be achieving the definition of done? Reducing scope reduces value delivered. I could focus more during the sprint to reduce the time it takes to read a page and so increase the number of pages I can read during each sprint.
Of course, if I’d spent the time reading instead of writing this blog post I’d be even further forward.
As we figure out how to go about bringing the management of our ecommerce platform in-house and fit it into our existing product management approach, some questions about the roles people play have come up.
In the old way of doing things, as the ecommerce subject matter expert, person with the most Magento knowledge, and owner of the relationship with the agency, the role of Product Manager would have fallen to me. But that doesn’t fit with the new way of doing things.
In the new way of doing things, I’m the customer (which seems a little non-sensical to me as I’m not the end user who will be extracting value), and we’ll have a Product Manager who will collect my requirements and write user stories for the Developer, and a Delivery Lead who will manage development.
It’ll be a challenge for me to give up control to others but I know it has the potential to be better in the future, and I think it’ll be a challenge for the Product Manager and Delivery Lead who are already at full capacity
