The Plan

Identify the need and the value
1. What's the vision
  1. This provides an overarching goal that everyone, including Stakeholders & Development teams can understand, share and work towards together
2. What does this look like?
  1. Target Group
    1. Who are the target customers/users for this product?
  2. Needs
    1. What are the needs of the Target Group?
    2. How will this product create value for them?
    3. What emotions will we evoke with our Target Group?
  3. High level scope
  4. Basic business value model
  5. Capabilities
    1. What capabilities will we deliver to meet the needs of our Target Group?
  6. Value
    1. How will this product benefit the organisation?
      1. Increase revenue
      2. Reduce costs?
      3. Create valuable knowledge
      4. Improve regulatory compliance
3. Prior experience?
  1. I've had experience in defining business cases, both as part of leadership courses and in my KPIs at WDS. I have also conducted traditional business analysis and have worked closely with product managers where software development process has integrated with an overarching product development processes
Prioritisation
1. What does this look like?
  1. Your team can’t deliver everything simultaneously, so they need guidance on the order in which the goals within the vision need to be realised
  2. Stakeholders and the product management team can start to define this order at a high level
2. Frequently review the roadmap according to market stability and product age
3. What's the roadmap?
  1. Order in which the vision goals are realised
  2. Date
    1. When will the release be available?
  3. Name
    1. What's it called?
  4. Goal
    1. Why should it be developed?
  5. Features
    1. What are it's key features?
  6. Metrics
    1. How do we know that the goal has been met?
4. What does the roadmap give us?
  1. Initial Product Backlog
  2. Business Value Model
  3. Critical Success Factors
  4. Definition of themes to group epics and stories under
5. Prior experience?
  1. I've worked with clients to plan out roadmaps that are driven by when capabilities are required to support business processes (client was a not-for-profit that distributes royalties bi-annually), but haven't directly planned roadmaps for products. I have worked closely with product managers and business analysts to deliver according to a roadmap (working on the IRIS Exchequer and IRIS Bookkeeping products), and I understand what a roadmap is, why it's important and how to define one as part of a team.
Release Planning
1. What does this look like?
  1. Velocity forecasts per sprint
  2. Actual velocity per sprint
  3. Slotting backlog items into sprints
  4. Can estimate using ROM estimate initially and work on getting the precision we are comfortable with at this stage of planning.
  5. Dependencies on earlier sprints
  6. Capabilities released in sprint
  7. Risk management and mitigating steps
  8. Constraints we need to deliver within
  9. Assumptions on current situation
2. What does release planning give us?
  1. Fixing time, budget & functionality is not possible; a compromise must be achieved
  2. Vision vs. Reality - The art of the possible
  3. which project lever—time, cost, or functionality—cannot be compromised to launch a successful product?
  4. The benefit of a predictable release cadence is that we can deliver value at a consistent rate to our customers
3. Prior experience?
  1. Release planning closely mirrors business analysis work I have performed in the past, both in product development and when performing professional services. We set the scope of the release, it's goal and success metrics. Define risks, constraints and assumptions. Define the high level capabilities the release will deliver as epics, in enough detail to allow working with engineering to define the lower level stories and get them estimated. When working with the not-for-profit client, we set up a Trello board where each column was a small release containing epics that delivered capabilities required in time for business processes to be executed by the client. These would be promoted to the sprint board during sprint planning. I have also worked in a traditional waterfall delivery style, using work breakdown structures, basic capacity planning, phased delivery, gated processes etc.
Sprint Planning
1. Prior experience?
  1. Held fortnightly sprint planning sessions with London based client using Plus for Trello using T-Shirt sizing for relative estimation, and reports from Trello to give actual velocity per sprint. I do sprint planning every week in my role in development at WDS.
2. What does sprint planning give us?
  1. Backlog of work defined in enough detail for the engineering team to deliver increments of business value
  2. The opportunity to communicate the goal of the iteration and answer any questions from the engineering team
3. What's in a sprint?
  1. A cost vs. business value prioritised short-horizon of work
  2. The perfect amount of work to fit the projected capacity of the team for the iteration
4. What does this look like?
  1. Meeting with the engineering team
  2. Prioritise the backlog in the sprint
  3. Work through each of the stories with the engineering team to communicate business value, acceptance criteria and to answer questions to enable the team to estimate the work
Daily Activities
1. Prior experience?
  1. Held remote stand-ups every day with London based client, using Trello as our scrum board. Defined acceptance tests and smoke tests, release checklist - since this was a legacy non-web project it was difficult to retrospectively add automation to our testing and release. I do daily planning every day in my role in development at WDS.
2. What does daily planning give us?
  1. Opportunity to check progress with the team
  2. Answer any questions the team might have
  3. Provide updates and context from the business where required
3. What does this look like?
  1. Daily stand-up
  2. Acceptance
  3. Working with the business to ensure we're building the right thing
Who would I speak to?
1. Stakeholders / Product Investment Board
2. Product Management
3. Customers
4. Sales
5. Support
6. Marketing
7. Engineering
8. UX Designers
9. Customer Release Managers
What tools would I use?
1. Mouth
2. Ears
3. Feet
4. Pen & Paper
5. Product Roadmap
6. Mock-ups
7. Vision Board
8. Top Support Issues
9. User Interviews
10. Product Delivery Framework
  1. https://confluence.wds.co/pages/viewpage.action?pageId=1245303
11. Burndown Chart
12. Theme/Epic/Story Mapping
Primary Role
1. Help position the development team for success in the iteration. For if they fail, you fail together.
2. Deliver business value as economically as possible
3. Checking Progress Ongoing
  1. Be available for acceptance
  2. Solution demo
  3. Retrospectives
  4. Keep the feedback loop between engineering and customers short
4. Building The Right Thing
  1. People don't want a quarter inch drill, they want a quarter inch hole
  2. Get the software in front of users
  3. Think about the most valuable small slice of the product to get to your users and work with the team to deliver that first
  4. Fail fast and pivot
  5. Test against the hypothesis
  6. Release early, fast and often - but with high quality
The Brief
1. You have been given responsibility of Acme Product.
2. You have little previous knowledge of the features and capabilities of the Product and some vague ideas from the Product Roadmap but the Engineering department are looking for direction on what to do next
3. Explain what actions you would take over the next few weeks and months to work this out.
4. Who would you talk to?
5. What tools would you use?
6. Be sure to explain how you would check progress ongoing.
7. Ensure that you are doing the right thing.
8. Be as specific as needed.
9. Try to use examples of previous experience where you have had to perform similar activities