Skip to main content

Author: Ryan Hewitt

Planning Workshops Using the 7Ps Technique

It’s difficult to plan for a workshop. There’s so many things to consider, sometimes it’s hard to know where to begin!

The best technique I’ve used for planning workshops is called the 7Ps. I found it in an excellent book called “Gamestorming”.

I use the 7Ps to create a clear agenda & make sure I’m prepared for a workshop.

How’s it work?

The technique asks you to consider the following areas for planning a workshop:

  1. Purpose – why are you having this session? I tend to write 3-4 bullet points to summarise the purpose. This is the most important question & worth starting with
  2. Product – what artifacts do we want to come away with from the workshop? You can think about this as outcomes or deliverables
  3. Process – what will the agenda be? This should tie back to the purpose. The process needs to ensure you achieve the purpose & come away with the products you want
  4. People – who will be in the session? And equally important – what role will they play? What kind of questions will they be there to answer? Will one person represent the technical side of the business. Will one person be there to sign-off the scope?
  5. Pitfalls – what are the risks of the meeting? E.g. a particular question that might blind side you, that some people will want to delve into detail. Think about these pitfalls & write down how you’ll mitigate them
  6. Preparation – what do you need to in advance of the session? E.g. do you need to create a presentation deck. Do you need to bring information to the meeting?
  7. Practical Concerns – these are things around logistics. Where’s the meeting? Do you have a TV? Who will meet the visitors etc

Working example

Below is an example of how I recently used the 7Ps.

I was planning for a workshop with a new vendor. We wanted an all day session to convey our initial requirements & allow the vendor to feedback on what they could deliver in their first release. It was also our kick-off session for agreeing how we’d work together on delivering a service.

I sketched out the below 7Ps and sent it to our team for internal feedback.

hewitt 010218a

  1. Purpose – 3-4 bullet points felt like the right level of detail. The above purpose was what I wanted to get from the meeting; however I also considered what others / the vendor would want to get out of
    it. It’s always worth thinking about other people’s expectations. I start on this section first – because that drives everything else
  2. Product – I find this to be the hardest section. In this example the product was a collective agreement of scope & how the scope would be delivered. The product was a NOW/NEXT/LATER roadmap which would be updated in the session. Sometimes the product isn’t tangible (e.g. getting everyone to understand why you’re making a change)
  3. Process – this was the next section I filled in. After identifying the purpose & product, I thought about what an agenda might look like / a typical running order. Each item here contributes to the purpose – and ensures we come away with the right products. Tieing the process back the above ensures that agenda items are necessary and add value
  4. People – this is always really useful. Sessions shouldn’t have more than 10 people. It’s useful to think about who needs to there – and what their role with be. A role might be: to answer technical questions, to represent the product team, to answer any questions around operations, or it can be a job title
  5. Pitfalls – I try to think about likely pitfalls. For our session, it was that that we would be drawn into the detail, and that we’d be asked a specific process question which we didn’t know the answer to. We actually invited the SME to mititgate that pitfall. And we created a question board where very specific questions could be parked
  6. Preparation – who will create the assets before the workshop? What will they create & bring? I put names & deliverables in this section for our workshop
  7. Practical Concerns – these are often things that people forget about. For our meeting it was: booking people onsite with security, checking the room has a TV, booking a room all day so that we could setup ahead of time. This became a checklist to make sure we were ready to run the workshop

Advertisement

Summary

I find the 7Ps a really good technique for conducting focussed workshops.

I typically use the 7Ps on my own to create an agenda, then take a picture and get people’s thoughts. This way attendees can feedback on the agenda. I find the “Process” & “People” sections are particuarly valuable for getting feedback & co-designing an agenda.

I find creating a physical version of the 7Ps means I can cross things out & move between sections easily. I often move from one section to another – and back again – as its all interconnected.

Hopefully you found this article interesting. And it’s a technique you would consider when planning for large workshops 

Applying Agile Principles to Requirement Analysis

Background

The Agile methodology originated within the software development industry. Since its inception in 2001 – Agile has expanded beyond an initial developer-centric community – to being embraced by multi-discipline teams working across numerous industries.

The antecedent of Agile within IT was the Waterfall methodology. The Waterfall framework consisted of a series of sequential, discrete phases – with each phase conveniently mapped to a role/responsibly:

Analysis Phase -> Requirement Analysis (Business Analysts/Product Owners)
Design Phase -> UX (Designers/Usability Experts)
Development Phase -> Software Development (Developers)
Testing Phase -> QA (Manual Testers and Developers in Test)
Delivery Phase -> Release Management (Project Managers)

Due to the increasing popularity of Agile – requirement analysis has been encouraged to transition from being a stand-alone phase owned by BAs/POs – to become a project facet that can incorporate Agile principles.

In what ways can requirement analysis adopt Agile principles?

Collaborative requirement analysis

Prior to Agile – the practice of the development team being presented with an upfront, non-negotiable, detailed requirements document (BRD/functional specification etc) was common. With the advent of Agile – requirement analysis should no longer be restricted to the interaction between BAs/POs and the business – instead we should embrace collaborative requirement analysis:

A popular collaborative requirement technique is the “3 Amigos”. This process involves the developer, BA and QA discussing the requirement specification in a workshop. Each Amigo will offer a unique perspective – through discussions the Amigos will identify edge cases, undefined requirements, opportunities and potential reuse. The 3 Amigos technique can also reduce the risk of incomplete features being pushed into development by the product team – requirement specifications must be pulled into development when they have been reviewed and accepted by the 3 Amigos.

Collaborative requirement analysis facilitates a project-wide sense of ownership – and also communicates a common understanding of what features need to be built. Collaborative requirement analysis produces more robust specifications – and reduces the role-based silos that can exist on projects.

Detail as an emergent property

Agile artefacts such as technical spikes and development iterations mean that high-level requirements can be considered sufficient at project initiation. Low fidelity requirement assets (e.g. user stories /”back of the napkin” designs) should be employed on Agile projects:

Just-in-time requirements analysis (JITRA) has a concept that requirements should only be specified at the level of detail required for upcoming development. JITRA states that the further in advance of development requirements are defined – the more probable that requirements will become out of date, leading to rework and wasted effort.

Detail should emerge when it is required – which is typically towards the middle/end of the project lifecycle. Initial requirement analysis should be focussed on business justification and solution scope.

Embrace change

Specifications will evolve throughout the project lifecycle; all team members must acknowledge the benefit of responding to change. Adapting to changes in circumstances/urgency/understanding is crucial – requirement analysis should be considered an iterative rather than exhaustive process:

In terms of systems theory – project teams should be viewed as open systems. As the system will tend towards a steady state – change should be encouraged and communicated at an organisational level. Regular priority sessions, stakeholder workshops and competitor reviews should be used to mitigate resistance to change.

Incorporating feedback is crucial to the success of a project. Requirements are not unchangeable statements – they only reflect the current and expected situation, both of which are liable to change.

Necessary documentation

The adoption of Agile principles does not mean that requirements should not be documented. Requirement documentation is vital for developers, QA and the business stakeholders:

The principle of living documentation should be embraced. This means that all documentation needs to be accessible and up-to date. Business users, developers and QA should be able to request requirement changes.

Documentation is most valuable when it is understandable by all team members, available and responsive to change.

Lightweight documentation such as feature files and high level process maps summarise the output of the requirement analysis process. The Agile methodology encourages appropriate documentation – superfluous detail is wasted effort; Agile does not negate documentation.

Continuous process improvement

Requirement processes should not be viewed as immovable obstacles. Instead these processes should evolve and adapt to meet the needs of the project. Where a process or artefact ceases to produce the expected value –it should be reviewed and changed by a self-organising team:

Retrospectives are a popular technique for identifying improvement opportunities. Team members meet to discuss what the team needs start doing, stop doing, and continue doing. Regular (every 2/3 weeks) and actionable retrospectives provide an open forum for continuous process improvement.

Requirement analysis processes (to-be-analysis, process mapping, stakeholder workshops etc) can always be improved. A technique that is effective for one team – may not be effective for another – or at least may require several modifications.

Continuous delivery

The Agile methodology promotes product iterations and regular releases. In order to align with this ethos, requirement analysis must produce a constant output – a steady flow of requirements will avoid the “big bang” requirement delivery that characterised the Waterfall methodology:

Minimum Viable Product (MVP) provides the scope of requirement analysis. The MVP will be delivered in multiple iterations – requirement analysis must be constantly baselined against the MVP and ensure that there is a sufficient specification available for each delivery.

Shorter delivery timescales encourages more frequent requirement analysis output. Specifications should be aligned to the MVP – features need to be deliverable and contribute to the MVP vision.

Conclusion

Iterative, collaborative Agile development has replaced the sequential Waterfall development methodology. Prior to Agile – the product team could hand over a list of detailed requirements – which would then be used by developers to build the product. In order to align requirement analysis with Agile development practices – the following principles need to be applied: requirement collaboration, iterative specifications, embracing change, necessary documentation, continuous improvement and continuous delivery. By adopting these principles requirement analysis will transition into the Agile world, produce better specifications and ultimately lead to greater quality products.

Don’t forget to leave your comments below.

User stories – WHO wants them, WHAT are they and WHY use them?

Introduction

User stories are a popular technique for capturing high-level requirements. User stories provide the rationale and basic description of a new feature request. The following format is the most recognisable user story template:

As a
I want
So that

Agile teams adopting the user story technique often struggle with questions such as: WHO are user stories produced for? WHAT do good user stories look like? WHY maintain user stories instead of more detailed requirement specifications? To answer these questions – I will recycle the who/what/why template of user stories.

WHO wants user stories?

  • Project stakeholders: these individuals want an easy method to pin ideas to the product backlog. With user stories – ideas don’t need to be defined in detail – the user story will provide a “placeholder for a conversation”.
  • The end user: teams that are able to elicit requirements directly from end users can use this technique to facilitate the discussion and documentation of feature requests. What does the user want to do? Why?
  • Project Manager/Product Owner: when grooming the product backlog – user stories are much easier to prioritise than detailed requirement specifications. User stories provide a non-technical, concise summary for the product team to decide the primacy of a feature.

WHAT are user stories?

  • Definition: User stories describe the desired interaction/dialogue between a user and the system. User stories provide the user’s rationale for a feature.
  • Typical format:
    • AS A [actor/user role] – this can be referred to as the WHO section. Who wants this feature? The user could be a generic actor (e.g. AS A user of the website), or a specific user role (e.g. AS A frequent business traveller), or even another system (AS A BACS payment system). Actors can be identified by internal discussions within the project team – identifying user roles may require more sophisticated analysis (e.g. profiling activities by the marketing department, transaction analysis, industry segmentations etc).
    • I WANT [feature/action] – this can be referred to as the WHAT section. What does the user want? The user will typically want the system to perform a new behaviour e.g. I WANT the ability to track an order, I WANT to pay for orders using an AMEX card, I WANT to cancel an order without any hassle.
    • SO THAT [benefit] – this can be referred to as the WHY section. Why does a user want this functionality? This section provides the justification/benefit of the feature.
  • Characteristics of good user stories: the INVEST acronym is frequently used to describe attributes of a good user story:
    • Independent
    • Negotiable
    • Valuable/Vertical
    • Estimable
    • Sized Appropriately/Small
    • Testable

WHY use user stories?

  • Requirements as an emergent property: user stories provide the Business Analyst with a springboard for analysis. A single user story (e.g. AS A price sensitive user, I WANT to be able to cancel my order, SO THAT I do not get charged by the bank for exceeding their overdraft limit) can lead to multiple scenarios for the BA. What is the happy path of this user story? What are the edge cases (e.g. what if some of the items were reduced as part of a promotion)? What are the business rules (e.g. full refunds are only provided up to 3 days from when the transaction was processed)? Requirements should emerge from user stories (not vice versa) – all requirements should have a user justification.
  • Maintenance of the backlog: the detail of a feature is abstracted a level below user stories. In addition – user stories should have few/no dependencies (refer to the INVEST acronym) – this means that user stories are lightweight additions to the product backlog and are therefore easy to maintain.
  • Available for discussion: user stories should be understandable by business users/end users/developers/all team members. User stories facilitate cross-role discussions and encourage open communication between various project silos.
  • Trees and forests: Working at a detailed level can occasionally mean that some requirements are not identified. User stories provide a way to mitigate the probability that user journeys are missed by the team.

Conclusion

User stories provide the team with a method to capture and discuss high-level requirements. Good user stories follow the INVEST acronym and provide the user’s justification for a new feature. Within Scrum/Agile teams – user stories provide an abstraction of requirement details – this facilitates maintenance of the backlog and provides the team with a “placeholder for a conversation”.

Don’t forget to leave your comments below.