Roger Swannell

Page 2 of 113

Project documentation: Just enough just in time.

One of the projects I work on has lots of documentation; functional design documents, technical specification documents, interface design documents, etc., etc. These are mostly so there is agreement about what is going to be built and as a reference afterwards for the teams that work with and maintain the system. Having lots of documentation makes some sense, gives some assurance and confidence, but it takes a long time to write and agree.

I’m also working on another project that as yet, has very little documentation. And one of the things we need to figure out as we progress through this project is how to document it effectively.

So how much documentation is enough? How do you get the right amount of the right kind of documentation at the right time? I think it should probably start with understanding what you aim to achieve. If you want documentation that enables you to all agree what to build, that should be different from documentation that records the results of testing, which is going to be different from documentation that creates an encyclopedic knowledgebase that enables other developers and users to be able to understand the decisions that were made during building.

For our project, my aim is just enough just in time. The documentation should grow with the project, alongside it, and at the same time. So the first step is high level requirements that enable us to complete the discovery work. We’ll then figure out the next phase and what documentation is needed to support that. It might be that the high level requirements evolve into user stories or more detailed business requirements, but this evolution will provide just enough information for the next phase just in time for the next phase to start.

Weekly Update 82

Last week’s update…

What happened this week…

  • Met with our UX Designer to brief.
  • Optimising Fascinator pages to enhance google shopping ads.
  • Added more free downloads onto the Online Shop.
  • Recruited a Magento Developer.
  • Discussed selling Defibrillators online.
  • Started work on creating an Ecommerce team site on Sharepoint.
  • Began setting up a MyMarathon Facebook Shop.
  • Wrote a User Guide to Freshdesk.
  • Met with our warehouse team to discuss future plans.

Read this week…

Doing next week…

  • Magento Roadmapping Session.
  • Project planning for selling Fascinators on Amazon.
  • Writing future Order Management scenarios.
  • Meeting with the Accessories Team to discuss the future clothing range.
  • Discussing marketing planning for selling Defibrillators.
  • Testing and training with Freshdesk.
  • Attending a branded merchandise boutique.

Interesting stat of the week…

  • Since April last year, 9.98% of our revenue has come from Pin Badges, 13.46% from clothing, and Christmas cards are still winning with 17.32%.

In the not too distant future….

  • Selling Fascinators on Amazon.

From working with an agency to working with a freelancer

Another example of figuring out how to work in a more Agile way in a risk-averse culture.

When you’re risk-averse, finding the right agency takes months. You follow the Procurement Policy, go out to tender to get five responses, do Dun & Bradstreet assessment, negotiate the contract, and then eventually you get to work.

When you embrace the uncertainty, finding a freelance developer takes days. You message a few on LinkedIn, have an informal phone interview, pick which one can do what you need and get them started.

There’s risk in moving from building a website with a reliable agency who you can have faith will be there tomorrow and next week and next month when you need them, to using freelance developers who can move on and take their knowledge with them at any time. So, how can you manage this risk?

Embracing the uncertainty, you make decisions quickly with what information you have, you break the work into small chunks, do a few pieces of work and then decide what’s next rather than creating a plan at the beginning of the project.

Will it work? We’ll find out over the next few months.

Moving to Scrum roles

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

User stories or business requirements

Why write User Stories?

User stories help us to understand what a customer needs to happen in order for them to achieve their objective.

User stories are one of the outputs in the journey of helping customers achieve their outcomes, but they are only an effective toll for this if the other steps of the journey have lead us this way. If we’ve never spoken to a customer to understand their needs, then we cannot write an authentic user story to express those needs.

Often, rather than having user stories that express the value outcome a customer is going to achieve, we have business requirements that describe the functionality the business expects to be delivered.


Writing business requirements instead

Business requirements are different to user stories. They are taken from parts of the business that haven’t spoken to any customers and express what is expected to be delivered in return for the investment of time and/or money.

Writing business requirements isn’t bad. It isn’t any less agile than writing user stories, but it is what it is, and shouldn’t be falsely wrapped up to look like user stories and pretend that they originated from the customer or to convince us that by delivering against those requirements we’ll achieve something for the customer.


Both are about delivering value

Both user stories and business requirements have their place. They both express a value exchange. One is between the customer and the business, and the other is between two parts of the business. If we want to deliver value continuously (which we most definitely should) then we need to be clear who we’re delivering value to.

Weekly Update 81

Last week’s update…

What happened this week…

Set up the new Running Shorts on the Online Shop.

  • Added downloadable heart health resources to the Online Shop.
  • Ecommerce Order Management scenarios, workflows, and a user guide.
  • Reviewed Wedding advertising performance.
  • Planned the supporter product range.
  • Planning Event Clothing marketing and retargeting campaigns.
  • Discussed the testing plan for the AX interfaces with Magento.
  • Started writing a user guide for using Freshdesk for Ecommerce Customer Service.

Read this week…

Doing next week…

  • Finalising requirements for AX Magento interfaces.
  • Optimising product pages for Google Shopping Ads.
  • Meeting with the Digital Team Delivery Lead to discuss working practices.
  • Discussing Returns and Refunds processes in AX.
  • Meeting with the UX Team to discuss the rebranding of the Online Shop.
  • Meeting with the Retail Customer Services Team to set them up on Freshdesk.
  • Meeting with the Accessories Buying Team to discuss expanding our clothing range.

Interesting stat of the week…

  • Across the entire product range the average rate of sale is 3.69 units a week, with the top performing 10% of products having an average rate of sale of 28.6 units a week, and the best seller having a rate of sale of 203 units a week.

In the not too distant future….

  • More coordinated approaches to customer services and logistics.

Using Scrum vs. ‘Whatever it is that we do’

I’m not sure what you’d call our way of managing work, but this is what we do: We spend two minutes every week moving cards on our Trello board to show what we’ll be working on that week, and then we trust each other to get on with prioritising our own workload and working on with the things that have the most impact.

The Digital Team use Scrum. The Product Owner raises tickets in Jira, writes user stories, and prioritises the work they want done. The Dev team estimate the work, add it to the backlog and decide which sprint to fit it in. Once the dev work is complete the Test team test it and if the work passes it is deployed to the live environment. The Delivery Lead manages it all.

I don’t know what you call whatever it is that we do, but I like it.

EbayBot Part 1: Getting search results

The British Heart Foundation eBay store is probably one of the most successful charity stores on eBay. It has thousands of listings of all kinds of interesting and unique items that have been donated to the BHF to raise money for life saving research into all kinds of heart conditions.


British Heart Foundation eBay Store

I wanted to build a Chatbot that could search the listings of a specific eBay store and return results based on a user inputted search term. The idea was simple; the bot asks the user what they are looking for, the user enters their search term, e.g. “camera”, and the bot returns all the listings on the BHF eBay store that match.


I broke the flow into three parts: Getting the search results, displaying the search results, and filtering the search results.


This was my first bot using an API to pull data from the web so I had a lot to learn about how to get the search results from eBay. And I didn’t really know how I was going to get the results to display in a chatbot, which listing info was essential and which I could do without, but I knew that with thousands of products on the BHF eBay Store at any one time, the third stage of filtering the listings was going to be essential for making the chatbot useful.


Getting the search results

I started by creating a developer account with ebay to get access to this suite of API’s.


Ebay has an API called ‘findItemsIneBayStores’ but I couldn’t get it to return results for the BHF store. A quick bit of Goggling showed that this API was known to be unreliable so I moved on to using the ‘findItemsAdvanced’ API.


This gave me greater control over the returning results which meant that I could pull results only for the correct store and get the elements I wanted to display to the user: Listing name, image, url on eBay. This API also allowed me to limit the number of returning results and display them in order of finished soonest first. Doing this would reduce the amount of filtering the user would have to do to find an item they were interested in.


So, when the flow was the started, EbayBot asks the user what they would like to search for. The users types ‘camera’

eBay Bot user search camera

The bot then uses the eBay API to pull back data for active listings in the BHF store that contain the keyword ‘camera’.


Getting reliable search results returned in JSON format was great. Now I had all the data I needed.


The next steps

The next step will be to figure the best way to display these results to the user in the chat flow. I think it’ll probably be a set of image cards that show the listing title, an image of the product, perhaps the current price, and either a link to the listing on eBay or a button to look at a single listing in more detail. I think this user experience decision comes down to whether users are likely to be able to choose the listing they are looking for with the first set of results, which means sending them out of the flow to eBay would be fine, or if the first set of results doesn’t give them enough info to choose, in which case i wouldn’t want them bouncing back and forth between the bot and the eBay website so I’ll make it so they can go into expanded information for each listing. I might also have a look at whether there is a way to identify if they have the eBay app installed on their phone and if so open that rather than link to the website.

Weekly Update 80

Last week’s update…

What happened this week…

  • Improved product images for pin badges.
  • Added product images to customer emails.
  • Reviewed the need for an Attributes interface into Magento.
  • Prepared for Brand Refresh work on the Online Shop.
  • Created a plan for the new clothing range on the Online Shop.
  • Workshop to review interface design between AX and the warehouse.
  • Added downloadable resources to the Online Shop.
  • Reviewed the sales Confirmation Interface Design Document.
  • Analysed the performance of the Gift From The Heart Range.
    Discussed London to Brighton 2019.

Read this week…

Doing next week…

  • Defining pricing logic for the Magento interface.
  • Planning the rebrand of the Online Shop.
  • Continuing to work on the Magento / AX requirements.
  • Revising the project plan for Freshdesk.
  • Image sourcing for ecards.
  • Discussing AX Interface Testing.

Interesting stat of the week…

  • Our Revenue Per Visitor has increased 14% against the same time last year.

In the not too distant future….

  • Signing off Interface Design Documents.
« Older posts Newer posts »

Copyright © 2018 Roger Swannell

Up ↑