Information Management Thinking

Meta
1

Hi all!

I’ve been working with Serenity and Kirsten and Sally to look at what tools we use for info mgt, based on all the different needs we have. First step in that process has been to look at the different user types we have involved in OFN and what their needs are.

I’ve had a first pass at this, was hoping y’all could have a look at it and fill in the gaps / fix the mistakes?

Cheers!

1. PRODUCT OWNERS

Who are they?

  • Serenity and Kirsten.
  • Melbourne-based, making decisions about product strategy and roadmap/backlog development and prioritisation.

What do they need?

  • Somewhere to develop and manage the high level roadmap.
  • Somewhere to communicate new things about OFN to stakeholders (roadmap, latest changes news).
  • Somewhere to define detail about features and stories in the backlog (descriptions, user acceptance criteria, etc).
  • Somewhere to manage leads/opportunities/connections (e.g. potential new customers or partners)

2. DEVELOPERS

Who are they?

  • Located in two different time zones (AU & UK).
  • A mix of medium to long-termers who constantly have their hands in the code and have a solid understanding of the code base, and ad-hoc freelancers doing feature-based development.

What do they need?

  • Somewhere collaborate on code development.
  • Somewhere for new developers to get up to speed and understand the code base.
  • Somewhere to view the backlog and select/complete stories in an iteration.

3. DESIGNERS

Who are they?

  • Melbourne-based?
  • Single designer at present?

What do they need?

  • Somewhere to collaborate on new designs.
  • Somewhere to get approval for new designs.
  • Somewhere to manage versions of new designs.
  • Somewhere to bring possible new designers up to speed.

4. ENTIRE PRODUCT DEVELOPMENT TEAM

Who are they?

  • All Product Owners, Developers, Designers, and anyone else who gets involved in the core team doing product development.

What do they need?

  • Somewhere to collaborate on iteration planning and management.
  • Somewhere to talk about admin/operations for OFN.
  • Somewhere to share news and tid bits of information relevant to OFN.

5. PRODUCERS AND HUBS

Who are they?

  • B2B Customers?
  • There are different levels of involvement from these guys:
    - Some want to be actively involved in the development process.
    - Some just want to push information (bugs / feedback / requests) to the team.
  • Potential Producers and Hubs who aren’t yet on OFN

What do they need?

  • Somewhere the explains what OFN is and how/why they should use it.
  • Somewhere that explains how to use OFN
    • Onboarding
    • Using different features
  • Somewhere to provide feedback about existing functionality.
  • Somewhere to suggest new features and functionality.
  • Somewhere to see the roadmap of new features to come.
  • Somewhere to get personalised help if I need it.
  • Somewhere to talk to other producers/hubs, to connect and give/receive advice.

6. INVESTORS

Who are they?

  • People who invested in the crowd funding campaign.

What do they need?

  • Somewhere that explains how it’s all going and how the money is being spent.

7. OTHER INTERESTED PARTIES

Who are they?

  • People in other countries who are interested in how OFN goes and whether they decide to open a branch in their country.

What do they need?

  • Somewhere that explains the latest news about OFN and the roadmap.
2

Hi again all,

So to continue this thread of thinking, we defined key areas where there was an information management need. It would be great if you could read through this and fill in any gaps or suggest alternative ideas. Cheers!

  1. Managing the Product Roadmap
    The Product Roadmap is a high level backlog/wishlist of features. Management of the roadmap involves adding new items, discussing how they would work and how important they are, prioritising them, and then designing those selected till they are ready for development. The Product Owners are accountable for overall management of the roadmap.

  2. Managing the Pipeline of Work
    The Pipeline of Work is the backlog of features that have made it across from the Roadmap and are ready to be developed. Management of the pipeline involves breaking the features down into deliverable chunks of work, adding them to iterations, developing them, testing them, and when ready deploying the new features as a release. The Development Team are accountable for overall management of the pipeline.

  3. Managing Leads and Opportunities - work being undertaken by Sally to find a CRM
    Leads and Opportunities are potential customers, partners or other interested parties of the OFN. Management of these involves recording their details along with any contact the OFN team have with them.

  4. Managing External Communication - to be considered at a later date
    External Communication is either the feed of news and information or the two-way conversation that the OFN team provide for stakeholders. Management of this involves providing the latest information about the OFN, and providing a place for a conversation.

MANAGING THE PRODUCT ROADMAP

Tools of choice

Inputs

  • Community Members (including customers, interested parties, the OFN product development team, etc) can add proposed features on the forum.

  • Any suggestions or new ideas provided via email or other channels will be added to the forum by the team.

  • Community Members can add their thoughts about the proposed features and vote for those features they think are most important.

  • The Product Owners will manage the prioritisation of these features, incorporating the feedback and measuring them against the Product goals.

  • Any features considered priority by the Product Owners will then be picked up by the UI/UX team members to design. The forum will be the place where design feedback and iterations will be posted.

  • Once the design is considered to be complete, the feature can then be added to the Pipeline of Work to be developed.

MANAGING THE PIPELINE OF WORK

Tools of choice

  • Backlog of features and tasks (TBD, currently on the wall in the office but could we use GitHub to cater for UK team?)

  • Code base development and history (GitHub - https://github.com/openfoodfoundation/openfoodnetwork)

  • Testing (TBD, currently a mix of GitHub and BugHerd but causes a duplication of effort)

  • Managing releases (TBD, not sure how this is being managed)

  • Communicating changes (Discourse for member announcements and userguides, TBD for more general announcements)

Inputs

  • Development Team will manage the creation of features/tasks based on the information provided in the Roadmap into a backlog.

  • Development Team will manage which features/tasks are added into each iteration. Once in an iteration the features/tasks must be included in GitHub (if not earlier so as to include the UK team in the task of defining and prioritising and iteration planning).

  • Development Team will manage the development of features/tasks in the code base in GitHub.

  • Anyone testing the new features/tasks will do so based on what is defined in the Roadmap, with any additional information they require in GitHub.

  • Any bugs are added to GitHub (this is where the developers work so it would make sense to include them against an iteration/milestone rather than in another application such as BugHerd).

  • TBD - how to manage a release within this process.

  • Any new releases include user guides for any changes to existing or new features. These are to be included on the forums (correct?).

  • The Product Owner will then announce the new release on the forum/etc once the release is deployed.

3

This is of course awesome, looking forward to getting the TBD’s sorted out - and also getting clearer on level of detail required at different stages. Would appreciate thoughts from @RohanM @oeoeaio @summerscope @sstead @NickWeir @pmackay @lynne (nick can you forward to Alexis and/or other UK testing team - they’re not signed up here yet so I can’t ‘ping’ them

I’m not sure about a couple of the steps in MANAGING THE PIPELINE OF WORK - after a couple of weeks of experimenting I think it’s quite unrealistic to maintain a ‘copy’ of the wall on github. I wonder if we need to do some more work on the categories in here so that we can move feature suggestions; to features ‘designed’ and then put them into the development/backlog when they’re ready?

I’m also wrestling a little bit with ‘features’ vs ‘fixes / updates’ where we have a whole bunch of small (and some larger) things to fix or that we’d like to improve on key pages / functions in OFN . .

4

Further thinking on how we’ll use Discourse for managing the Product Roadmap, descriptions of current features, and backlog items.

MANAGING & DESCRIBING CURRENT FEATURES

Discourse will be the place to find the detail about a) what features are currently built and released on OFN, and b) how these features are currently implemented.

There will be:

  • A page that has a list of all current features on OFN (like a table of contents).

  • A page per current feature (linked to on the list page)

    • There will be an overview of current functionality and will include screenshots.
    • Each topic will be in the category “Feature”.

The list view is likely to be based off the table of contents being put together for the How-to section of the website. The current feature pages will be updated as they are developed, and used as the source for creating and updating the How-to content.

MANAGING & DEFINING PRODUCT ROADMAP

The current Product Roadmap page on Discourse will be updated so that it only includes items/features that are actually in the roadmap rather than also having the total feature set.

It will be a list view, where each item links off to either a WISHLIST topic, or a BACKLOG topic for that roadmap feature.

WISHLIST

  • The wishlist topic will include all the possible ways that a feature in the Roadmap can be further developed. It will be the place for discussions around these suggestions, for images of sketch sessions, and for defining discrete pieces of work that can be added to the backlog for development (e.g Customer Accounts Phase 1 - customer interface).

  • Each topic will be categorised as “Wishlist”

  • These pages will also be linked to from the Current Feature page, so that anyone viewing the details of how a particular feature works can also jump over to see proposed future improvements.

  • Each topic will be laid out in a templated way, so that it’s easy to pick up what kind of details can be found on the page and where people can contribute.

BACKLOG

  • The backlog topic will be used as the place to define each discrete piece of work that will be developed for a feature. The details can come from the feature’s wishlist topic, or can be directly linked to from the Product Roadmap.

  • Each topic will be categorised as “Backlog”

  • Once a backlog topic is set up, the scope of the development is defined (sketching notes, UI design, acceptance criteria for testing, etc).

  • Once all of this detail is defined then it’s ready for the Development backlog (marked with Sub-Category “Ready”)

    • Provides the high level view of what is being developed
    • GitHub will be used for managing the delivery of what is defined (ie. breaking it into tasks and managing via milestones to completion).

  • Testing of what is developed is done using the acceptance criteria/scope description defined in the backlog topic (For items marked with Sub-Category “Testing”.

  • Once the work is completed, the detail of the change can be fed into the relevant Current Feature description, and the topic set to “Complete”.