R&D Toolkit
  1. Overview
      2. Overview
    1. Introduction
      2.
      1. Recent Updates
        2.
    2. Tools
      3.
      1. Research
        2.
      2. Delivery
        3.
    3. Resources
      4.
      1. R&D
        2.
      2. Websites
        3.
      3. Project Tracking
        4.
      4. Further Resources
        5.
  2. Research
      3. Research Tools
    1. Problem
      2.
      1. Discovery
        2.
      2. Prioritisation
        3.
      3. Project Scoping
        4.
      4. Framing
        5.
    2. Empathise
      3.
      1. Investigate
        2.
      2. User Interview
        3.
      3. User Insights
        4.
      4. Data
        5.
    3. Mapping
      4.
      1. Research Mapping
        2.
      2. User Mapping
        3.
      3. Organisation Mapping
        4.
    4. Synthesis
      5.
      1. Problem Reframing
        2.
      2. Define
        3.
      3. Feature Prioritisation
        4.
  3. Design
      4. Design Tools
    1. Ideation
      2.
      1. Warm Up
        2.
      2. Sketching
        3.
      3. Storyboarding
        4.
      4. Design Studio
        5.
  4. Delivery
      5. Delivery Tools
    1. Agile
      2.
    2. Scrum
      3.
      1. Overview
        2.
      2. Team
        3.
      3. Events
        4.
      4. Artifacts
        5.
      5. Glossary
        6.

marc.tools

A Product R&D Toolkit

Welcome. I'm Marc and this is a Toolkit to create things.
R&D Toolkit    Delivery Tools
Delivery

One of the biggest challenges for any team or organisation, from startup to corporate is delivering the vision of the product. Translating the user needs in to tangible outputs in an organised, efficient way.

The following methodologies and frameworks can support this process by both pushing the theory of team organisation and creation, along with clear, transparent and trackable progress.

Tool Sections
Agile
Scrum
  
R&D Toolkit    Delivery

Software development is a unique way of building things and requires an adaptable team that can respond to changes seamlessly and the Agile Methodology fits in perfectly with this need and Project Management in general.

The Manifesto for Agile Software Development helped push Agile in to the mainstream, by defining principles and core values, it clarified what constitutes Agile thinking. This Manifesto was derived from a number of software development frameworks, notably Kanban and Scrum.

Further Resources
  Agile Methodology: An Overview
  What is agile methodology? Modern software development explained
  Agile software development

12 Principles

  • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  • Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
  • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  • Business people and developers must work together daily throughout the project.
  • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  • Working software is the primary measure of progress.
  • Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  • Continuous attention to technical excellence and good design enhances agility.
  • Simplicity--the art of maximizing the amount of work not done--is essential.
  • The best architectures, requirements, and designs emerge from self-organizing teams.
  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

4 Core Values

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Acronym for the overarching product delivery process. A way of starting at a high level (Company themes) that are then broken down incrementally as a way of building the product iteratively.

Themes

Themes are long term strategic business goals that usually span the next 1-3 quarters.

Initiatives

Initiatives derive from the Theme, and are broken down in a way that allows them to be delivered in a Quarter.

Epics

From Initiatives, Epics are extracted that will take 1-3 Sprints to deliver.

Stories

Stories, either user or job, are created out of the Epic and should be small enough for a development team to deliver in 1-3 days.

Template

Further Resources
  Epics, Stories, Themes, and Initiatives
  Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds
  
R&D Toolkit    Delivery

A framework that sits within Agile methodology, Scrum encourages lean product development by encouraging people to self organise in a way that can solve complex problems.

By defining roles and breaking product development down in to items, Scrum allows for full transparency of the work and value of the team as it moves through the creation process.

Then using events (Ceremonies), Scrum pushes for introspection, adaption and ultimately team improvement that helps to make any product development extremely efficient.

Scrum Sections
  

Scrum Team

The Scrum team is made up of 3 core stakeholders. These 3 roles describe what is expected of the team, and are not job titles - in fact, the titles are adopted only for the Scrum process - not permanently.

The Scrum Master is responsibly for keeping a Sprint on track, and making sure the team are maximising value. They will spend a large amount of time ensuring best practice is happening, and continue to promote the Scrum Framework, and will work to resolve any blockers that may rise during the Sprint.

A Scrum Master is a wonderful role to have in the process and it is important that this person is easy to communicate with, interact with and holds the position of fair and balanced well.

The following is from https://www.scrumguides.org/scrum-guide.html#team

Scrum Master Service to the Product Owner

  • Ensuring that goals, scope, and product domain are understood by everyone on the Scrum Team as well as possible.
  • Finding techniques for effective Product Backlog management.
  • Helping the Scrum Team understand the need for clear and concise Product Backlog items.
  • Understanding product planning in an empirical environment.
  • Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value.
  • Understanding and practicing agility.
  • Facilitating Scrum events as requested or needed.

Scrum Master Service to the Development Team

  • Coaching the Development Team in self-organization and cross-functionality.
  • Helping the Development Team to create high-value products.
  • Removing impediments to the Development Team’s progress.
  • Facilitating Scrum events as requested or needed.
  • Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood.

Scrum Master Service to the Organization

  • Leading and coaching the organization in its Scrum adoption.
  • Planning Scrum implementations within the organization.
  • Helping employees and stakeholders understand and enact Scrum and empirical product development.
  • Causing change that increases the productivity of the Scrum Team.
  • Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization.

The development team can consist of a number of different roles that all contribute to producing the product. This is a self organising team that will take care of the design, development, UX, and testing.

The more common roles are;

  • Front End Developer
  • Back End Engineer
  • UX Designer
  • UI Designer

However, depending on the project, a number of other roles may also be involved with the development.

Generally the team is large enough to produce big enough outcomes, but small enough to remain nimble. Ideally the team will be more than 3, but less than 9. You may then have cross-discipline teams (also known as squads) whose backlog may be decided by a Scrum of Scrums event.

The Product Owner is generally the most important person in a Scrum team. They are responsible for maximising the resource and value derived from the process. They will prioritise and manager the product backlog, and will usually have the final say on any decisions.

The following is from https://www.scrumguides.org/scrum-guide.html#team-po

Product Backlog Management

  • Clearly expressing Product Backlog items.
  • Ordering the items in the Product Backlog to best achieve goals and missions.
  • Optimizing the value of the work the Development Team performs.
  • Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next.
  • Ensuring the Development Team understands items in the Product Backlog to the level needed.

For the Product Owner to succeed, the organisation and stakeholders must respect their decisions and must always be consulted if any backlog items need changing.

The Scrum team needn't be limited to just a core group. There is value to be added from a variety of stakeholders, and sometimes it is important to include others in order to achieve the desired outcome.

Other stakeholders can help during Sprint planning - particularly with prioritising, but also through fleshing out detail. Stakeholders can also be involved in the review, particularly if they will be utilising the new product.

  

Scrum Events

There are certain events that take place during the Scrum process that are important for organisation and transparancy. They also help with keeping things aligned to the the Agile methodology.

A method of breaking large bodies of works in to smaller pieces that are then time boxed. This allows for constant iteration and agile responses to changing market conditions.

Usually a month or less - but always a consistent time period - one or multiple product increments will be created or 'Done' in this period, and will be usually be releasable. By keeping the timeframe short, it reduces risk, feature creep and allows for flexibility if things need to change.

Sprint planning, daily stand ups, reviews and retrospective are all part of the Sprint, and as soon as a Sprint ends, the next will begin.

During the Sprint

  • No changes will be made that can endanger the sprint goal.
  • Quality goals do not decrease.
  • Scope may be further clarified and re-negotiated between Product Owner and Development team as more is learned.
  • A sprint can be cancelled if things change significantly during the period. Items that are Done can still be reviewed and released if the Product Owner wishes.

Do's

  • Keep everyone aligned by making sure everyone is aware upfront of what constitutes success and the overall sprint goal.
  • Keep backlog groomed to ensure correct priorities and reduce risk of derailing the process.
  • Have a good understanding of the velocity of the Scrum team.
  • Leave out items that won't be ready in time (if for example it's reliant on another team, or it needs legal sign off).
  • When a decision is made, capture it in the project management tool (Jira for example) so that transparency and reasoning are logged.

Dont's

  • Add too much to a Sprint - too many items, or overestimating velocity can set up a team to fail.
  • Forget technical or quality debt - some items will need improving, bugs fixing and QA.
  • Allow for team members not to be fully clear on what is being done - better to move in the same direction slowly, than fast in the wrong direction.
  • Take on a large amount of unknown, or high risk tasks - break it down and prioritise.
  • Ignore concerns. Address issues and re-assess items if required.

The time for the entire Scrum team to come together to plan the next sprint, covering what items will be included and estimating how long the items will take to complete.

Dependent on the length of the Sprint (usually a month or 6 weeks), this session will be time boxed to roughly 8 hours, with the Scrum Master leading and ensuring everything is kept to this period.

Formulating a sprint goal, the team will forecast what could be done from the product backlog in the following Sprint with the current resources in order to meet this goal.

The development team will then work with the Product Owner to define what done is, and if necessary renegotiate, re-estimate or re-prioritise the items.

Sprint Goal Template

Credit/Resources
  A Template for Formulating Great Sprint Goals
  Sprint Template

A Stand Up is daily meeting lead by the Scrum Master that is purposefully kept brief. It is a way of quickly updating the Scrum team on your progress.

It takes about a minute per person, and will cover What you worked on yesterday, What you're working on today, and if there are any blockers (where the Scrum Master may step in).

Further Reading
  What is a Daily Scum?
  Stand-ups for Agile Teams
  5 Scrum Meeting Best Practices
  Stand-up Meeting

A Sprint Review mainly consists of a casual demo session - the whole Scrum team (plus potentially other stakeholders) come together to show and explain what they've been working on and what's been 'done' - the definition of done might also be discussed.

The Product Owner may lead this demo depending on the Review, who is there and what has been worked on - but individual Scrum members may demo their own work if need be.

Other items that can be covered are;

  • What went well, what problems were encountered and how were they solved.
  • Any questions about an increment.
  • Discussion about the Product Backlog - usually by the Product Owner who might also discuss dates based on current progress.
  • The group may then discuss what to do next in order to feedback for Sprint planning.
  • Any changes in the market or other factors that may change priorities.
  • A review of the budget and other capabilities the next release.

Retrospectives are a simple way for a team to look back at a Sprint and analyse what went well and what didn't.

This isn't an opportunity to criticise team members, but an opportunity to improve and ties in nicely with the Agile Manifesto of teams meeting regularly to adjust and improve.

It can take a number of shapes, but is usually along the lines of;

  • Keep
  • Stop
  • Start

The whole team must be involved with a facilitator leading a meeting of between 30 mins and an hour. The focus will be on listing individual things that can then be grouped by theme and prioritised, with a plan of action with clear owners and due dates.

Retrospective Template

Further Reading
  Agile Retrospectives
  Scrum Retrospective
  

Scrum Artifacts

There are certain events that take place during the Scrum process that are important for organisation and transparancy. They also help with keeping things aligned to the the Agile methodology.

A backlog is comprised of a prioritised list of items. These items are usually features that have already been scoped out and are ready to be built.

Each Backlog item is sized in advance by the development team which helps the Product Owner prioritise the most important to the least.

This method of working helps particularly with agile, which allows for constant iteration and prioritisation before each sprint.

Additionally, with a Backlog in place the development team can continue to work on the next prioritised item if resource allows (usually because a task was completed quicker than expected).

The backlog is built up of a series of items derived from an epic (which in turn is derived from an overarching initiative which comes from a company theme).

Roadmap and Requirements

The Backlog largely stems from the Roadmap that is owned by the Product Manager - This Roadmap will be comprised of Themes that are broken in to Initiatives that are broken in to Epics that are finally broken in to Stories.

The Epics may be chosen to be delivered as a whole, or Stories may be taken from individual Epics to help with testing, or for launching an MVP. The Product Owner may choose to prioritise the Backlog for a number of reasons including;

  • Customer feedback
  • Resource requirements (estimation/sizing)
  • Relationship between items
  • Market conditions

The items in the Backlog could also be backed up by a requirements document (PRD) if there is a lot of technical information required.

Backlog Template

Backlog Maintenance

It is also important to ensure the Backlog is frequently groomed for old items that are no longer required through feedback or other reasons.

Additionally the backlog should be reviewed frequently (and before each planning meeting) to ensure the right things are being built in the right order.

Once a Backlog gets large enough, it may start to have both short term (fully fleshed out) and long term items. This is why regular grooming is important.

Stakeholders

Not only does a Backlog help keep Product and Development aligned, but also offers an insight to other Stakeholders. This is a good things as it allows for transparency across teams and the organisation, creating discussion points that will ultimately align everyone.

Additionally, it serves as a single source for all stakeholder items that cover all parts of the product;

  • Design Changes
  • Bugs
  • Stories
  • Customer Requests
  • Technical Debt
  • Retrospective Action Items
  • Etc

All of which are prioritised in a transparent reasonable way, thus keeping the organisation Agile.

Unlike a Product Backlog, a Sprint Backlog is a series of items that have been prioritised during Sprint Planning and are to be completed in that Sprint.

Forecast by the development team, its aim are to achieve the sprint goal and delivering the product increments.

Creating visibility amongst the team, with enough detail to be understand by the team and discussed during the daily stand-up, by tracking items in such a way it can show progress and therefore likelihood of reaching the goal.

The Sprint Backlog is managed by the development team, but usually only the scrum master can move items - if new things are required they can be added, completed items are logged and unnecessary items removed.

Sprint Backlog Template

An Increment takes the entire Product Backlog items that have been completed in a sprint, and meets the definition of "Done".

The Increment is added to the value of previous Increments and is another step towards the goal in completing the vision.

The Product Owner may or may not decide to release the Increment (owing to market or priority changes), but it must still be useable.

Transparency is incredibly important within Scrum. Where there is full transparency, decisions will have a sound justification, but if there is a lack of transparency, then decisions may be flawed and therefore increase risk and decreased value.

The Scrum Master will work with all members of the Scrum Team to make sure the Artifacts are completely transparent. It is their role to detect issues around transparency and work to solve them.

A Scrum Board is a helpful way of managing this transparency, by providing a visual and even physical space to show progress and provide updates.

Scrum Board Template

Definition of "Done"

For a team to function well, in an agile manor they must have a shared understanding of what constitutes an item or increment being "Done".

This definition of "Done" will create complete transparency, and will guide the team as to how many Product Backlog items it can select for a Sprint.

The definition may already be part of the guidelines for the organisation, but if it isn't then one must be define one appropriate for the product. Additionally, if there are multiple Scrum Teams then there must be a mutual agreement on the definition.

More experienced teams will have more stringent criteria for defining "Done" so as to ensure a higher quality product.

Done Template

  

Scrum Glossary

There are a number of terms within Scrum that are used uniquely, but are important to understand as they explain things concisely.

Term Meaning
Done A shared understanding in the Scrum team of when an item is complete on the Product Increment. The definition of Done helps guide how many items can be complete during a Sprint.
Estimation A method for calculating how long a specific item will take. This is usually done as a group exercise and will result in group agreement.
Grooming It is important to stay up top of Backlogs, and Grooming helps accomplish this by updating the Backlog as a team progresses through a sprint.
Increment A body of work that comes out of a Sprint that adds value to the product.
Item A specific feature or piece of work that is in the Backlog.
Scrum of Scrums Scrum of Scrums is a scaled agile technique that offers a way to connect multiple teams who need to work together to deliver complex solutions. More at https://www.atlassian.com/agile/scrum/scrum-of-scrums
Sprint Zero This is the first ever Sprint, starting from a completely fresh base, it is usually used as a means of setting up systems and processes ready for product development and future sprints.
Stand-Up A daily get together, usually at the start of the day where the team updates each other on progress, blockers and their plans.
Velocity The average speed at which sprint jobs are being completed.