×

What is the role of Business Analysts within agile?

Analysisng the role of the Business Analyst.

When we were looking at the Digital, Data and Technology (DDaT) roles and capabilities back in 2016, one of the roles we really struggled with was the role of the Business Analyst (BA).

Not because we didn’t agree that it was a role (because we absolutely did) but because we struggled to define the scope of the role in comparison to things like; Product Management, Design or User Research roles.

It’s one of the questions, that three years later still comes around regularly. Who is responsible for defining the requirements? What is the role of the BA?

Who holds the requirments?

The role of the BA in an agile team

One of the problems we had back when we were defining the BA role as part of the DDaT professions, was that the Government Digital Service didn’t have BA’s in their teams. Similarly, the original Scrum Manifesto only has 3 roles in an agile team, the product owner, development team members and scrum master.

Because traditionally, the BA acted as the link between the business units and IT, helping to discover the requirements and the solution to address them; when multidisciplinary teams bought those members together the role of the BA became less clear.

This has meant when adopting agile, different government departments implemented the role in slightly different ways. The biggest trap I have seen teams fall into was the BA getting stuck with all the admin roles for the project.

Roman Pilcher argued for those BA’s moving into Scrum there were two options, becoming the Product Owner, or becoming a ‘team member’.

While I agree that Business Analysts are a key member of a multidisciplinary team, I disagree with this assumption that everyone on an agile team who isn’t the scrum master or the PO is simply ‘a team member’ I think the Business Analyst is a critical role (especially for Product Managers!) that brings unique skills to the team.

So, first things first let’s look at what requirements are in the agile space.

Certainly, within digital government at least, we use a user centric design approach. We are developing products and services that fix the problems that our users are facing. We are identifying user needs and testing and iterating those throughout the product development lifecycle. A lot of the time this conversation about ‘user needs’ has replaced the more traditional conversations about ‘requirements’. Which is good in some ways, but has also led to a bit of confusion about what Business Analysts do if it’s not gathering requirements. Who owns the requirements now?

Are user researchers responsible for gathering the requirements from external users (user needs), whereas Business Analysts are responsible for gathering requirements based on what the business needs (sometimes called business user needs)?

That line of conversation worries me, because it suggests that we don’t need to carry out user research on internal staff, it forgets that internal staff are users too.

So, what is the role of the BA?

In my experience the conversation about who is responsible for gathering requirements is symptamatic of the limitations of the English language, and our obsession with ‘ownership’.

User researchers primarily focus on gathering more qualitative data; why users behave the way they do, how things are making them feel; probing their views and opinions to understand what it is they actually need etc. They will help understand who they users are and verify what the users need. They will work with the team to test design assumptions and help ensure the options being developed meet user needs.

Business Analysis primarily focus on gathering the more quantitative data about the process; both the ‘as is’ process, and the future process we are designing. They work to understand how many users are being or will be affected? What are the cost/time impacts of the problem as identified? What value could be gained through the implementation of any of the options the team are considering?

They help identify the stakeholders that will need to be engaged, and how to best engage with them. They will turn the user needs into user stories that the team can develop and identify the metrics and success criteria for the team to help them measure value.

Where you have a Product or Service that is live and being used by real users, the BA will work with Performance Analysts to understand the feedback data coming from the users.

User Researchers and Business Analysts will often work closely together, while BA’s will use tools like process mapping to identify pain points, user researchers will work with them to map the emotions users are experiencing so that we can fully understand the impact of our current processes and the value we can release by fixing the problem. When User Researchers are planning in research sessions etc., they will often work with BA’s to get the data on where best to test in terms of locations or user groups.

Good Product Managers will use both the Quantitative and Qualitative data to help them pick which options to test. Designers will help both the user researchers and business analysts look at the data and design prototypes etc. to test with users.

For me, each role is clear in its scope, and their need to work together to identify the right problems users are facing and the best way to test those; and it’s not about what individual owns the requirements, because the answer is the team do.

The Day Data went Viral

This week the UK Government and Parliament petitions website has been getting a lot of attention, both good and not so good. This site has been a great example of how the Digital Service Standards work to ensure what we deliver in the public sector meets user needs.

On the 20th of February a petition was created on the petitions website to Revoke Article 50 and remain within the EU, on the 21st of March the petition went viral, and as of writing this blog has currently got 5,536,580 5,608,428 5,714,965 signatures. This is the biggest petition to have ever been started since the sites launch. Not only that, it is now the most supported petition in the world, ever.

Screenshot of the petitions website

The first version of the site was developed in 2010 after the election. Originally intended to replace the Number 10 petition site, which had a subtly different purpose. The new version of the Parliamentary petitions site was then launched in 2015, as an easy way for users to make sure their concerns were heard by the government and parliament. The original version of the service was developed by Pete Herlihy and Mark O’Neill back in the very early days of Digital Government, before the Digital Service Standard was born.

The site was built using open source code, meaning anyone can access the source code used to build the site, making it is easy to interrogate the data. With a number of sites, like unboxed, developing tools to help map signatories of petitions etc based off the data available.

Screenshot of the unboxed website

Within the Governments Digital Design standards using open source code has always been one of the standards some departments have really struggled with, it’s digital standard number 8, and is often a bit contentious. But looking at the accusations being lobbied at the Revoke Article 50 petition, that people outside of the UK are unfairly signing the petition, that people are creating fake emails to sign the petition etc, it shows why open source data is so important. While the petitions committee won’t comment in detail about the security measures they use; examining the code you can see the validation the designers built into the site to try and ensure it was being used seurely and fairly.

britorbot data analysis

Speaking of security measures, that’s digital service standard number 7, making sure the service has the right security levels, the petitions site apparently uses both automated and manual techniques to spot bots; disposable email addresses and other fraudulent activities. This works with digital standard number 15, using tools for analysis that collect performance data; to monitor signing patterns etc. Analysing the data, 96% of signatories have been within the UK (what the committee would expect from a petition like this).

tweet from the Petitions Committee from 22nd March

Another key service standard is building a service that can be iterated and improved on a frequent basis (digital standard number 5), which mean that when the petition went viral, the team were able to spot that the site wasn’t coping with the frankly huge amount of traffic headed it’s way and quickly doubled the capacity of the service within a handful of hours.

tweet from Pete Herlihy (product manager – petitions website)

This also calls out the importance of testing your service end to end (standard number 10) and ensuring its scalable; and if and when it goes down (as the petitions website did a number of times given the large amount of traffic that hit it, you need to have a plan for what to do when it goes down (standard number 11), which for the poor Petitions team meant some very polite apologetic messages being shared over social media while the team worked hard and fast to get the service back online.

tweet from the Petitions Committee from 21st March

The staggering volume of traffic to the site, and the meteoric speed in which the petition went vial, shows that at its heart, the team who developed the service had followed Digital Service Standard number 1. Understand your user’s needs.

In today’s culture of social media, people have high expectations of services and departments with there interactions online, we live in a time of near instant news, entertainment and information- and an expectation of having the world available at our fingertips with a click of a button. People want and need to feel that their voice is being heard, and the petitions website tapped into that need, delivering it effectively under conditions that are unprecedented.

Interestingly when the site was first developed, Mark himself admitted they didn’t know if anyone would use it. There was a lot of concern from people that 100,000 signatures was too high a figure to trigger a debate; but within the first 100 days six petitions had already reached the threshold and become eligible for a debate in the Commons. Pete wrote a great blog back in 2011 summing up what those first 100 days looked like.

It’s an example of great form design, and following digital service standard number 12, it is simple and intuitive to use. This has not been recognised or celebrated enough over the last few days, both the hard work of the team who developed the service and those maintaining and iterating it today. In my opinion this service has proven over the last few days that it is a success, and that the principles behind the Digital Service Standards that provided the design foundations for the site are still relevant and adding value today.

tweet from Mark O’Neill (part of the original team)

Round and round we go.

In other words Agile isn’t linear so stop making it look like it is.

Most people within the public sector who work in Digital transformation have seen the GDS version of the Alpha lifecycle:

Which aims to demonstrate that developing services starts with user needs, and that projects will move from Discovery to Live, with iterations at each stage of the lifecycle.

The problem with this image of Agile is that it still makes the development of Products and Services seem linear, which it very rarely is. Most Products and Services I know, certainly the big complex ones, will need several cracks at a Discovery. They move into Alpha and then back to Discovery. They may get to Beta, stop and then start again. The more we move to a Service Design mentality, and approach problems holistically, the more complex we realise they are, and this means developing Products and Services that meet user needs is very rarely as simple and straightforward as the GDS Lifecycle makes it appear.

And this is fine, one of the core principles of Agile is failing fast. Stopping things rather than carrying on regardless. We iterate our Products and Services because we realise there is more to learn. More to Discover.

The problem is, especially in organisations new to Agile and the GDS way of working, they see the above image, and its more linear portrayal seems familiar and understandable to them, because they are generally user to Waterfall projects which are linear. So when something doesn’t move from Alpha to Beta, when it needs to go back into Discovery they see that as a failure of the team, of the Project. Sometimes it is, but more not always, sometimes the team have done exactly what they were meant to do, they realised the problem identified at the start wasn’t the right problem to fix because they have tested assumptions and learned from their research. This is what we want them to do.

The second problem with the image put forward in the GDS lifecycle is that it doesn’t demonstrate how additional features are added. The principle of Agile is getting the smallest usable bit of your Product or Service out and being used by users as soon as you can, the minimum viable product (MVP), and this is right. But once you have your MVP live what then? The Service Manual talks about keeping iterating in Live, but if your Product or Service is large or complex, then your MVP might just be for one of your user groups, and now you need to develop the rest. So what do you do? Do you go back into Discovery for the next user segment (ideally, if you need to yes), but the GDS lifecycle doesn’t show that.

As such, again for those organisations new to Agile, they don’t’ factor that in to their business cases, it’s not within the expectations of the stakeholders, and this is where Projects end up with bloated scopes and get stuck forever in Discovery or Alpha because the Project is too big to deliver.

With Public Services being developed to the Digital Service Standards set by GDS, we need a version of the lifecycle that breaks that linear mindset and helps everyone understand that within an Ariel project you will go around and around the lifecycle and back and forwards several times before you are done.

Agile is not a sprint, a race, or a marathon, it’s a game of snakes and ladders. You can get off, go back to the start or go back a phase or two if you need to. You win when all your user needs are met, but as user needs can change over time, you have to keep your eye on the board, and you only really stop playing once you decommission your Product or Service!


Why focusing on productivity isn’t productive.

One thing that comes up time and again from senior managers is “My focus or priority is improving Productivity”.

Early on in my career I worked on a number of ‘productivity improvement inniatives’ and sometimes they would seem to make some improvments, sometimes they wouldn’t, but they never really solved the issues and there always seemed to be more to do to ‘improve productivity’, so I began to wonder whether these projects were ready adding any value.

Nowadays when I talk to a manager to understand why they are prioritising any productivity initative, the answer is usually something like, “we can be more productive, it’ll help us cut costs and deliver a better service.” If I then ask how they plan to do this, the answer is generally “by improving our processes/ transforming our service/ getting more staff”.

Anyone who has ever been responsible for transforming processes or services acknowledges that when you introduce a change or a new way of working productivity drops, at least for a short time. This is a truth pretty much universally acknowledged. In fact lets repeat that, just to be clear, when you introduce any new change to processes, technology or ways of working productivity will drop. This can be as much as 30% while people learn the new processes, or get up to speed with any changes. This drop generally doesn’t last for too long, but it will happen.

Next, when you hire more staff, your existing high performing staff are often the ones tasked with training them and building capability. So, for those staff at least, productivity will drop while they help support and build the capability of your new staff. There’s evidence that it can take new staff 6-12 months to fully get to the same capability and productivity levels as existing staff, and that the productivity of the staff responsible for training and coaching them will be impacted as well.

This is all fine, as long as it is acknowledged upfront. If we tell people that we know their productivity will drop while they get up to speed with these new changes, or help train new staff, then we are helping to reassure them, and managing our own expectations.

But the biggest mistake I often see is a reluctance by senior managers to face that truth. We refuse to change people’s targets, we expect them to still meet the previous demands, and what happens?

First morale drops, and then productivity drops, morale drops more because people are struggling to meet unrealistic targets and then they leave or go off sick, and productivity drops further. In the end the change we’ve introduced fails or we have less staff than we did to start with and we’re actually achieving less than we did before not more. It is almost Oedipal in it’s obviousness, you can see it coming a mile off. So why do Managers do it?

For me this conversation comes down to Managers rather than Leaders, and a failure to look at the actual problem we are trying to fix.

When I work with organisations to understand the outcomes they are trying to reach, or the problems they are trying to fix, productivity is often mentioned, especially in operational delivery spaces.

But by working with both the leadership team and the people delivering on the front line, productivity itself is never really the problem. It’s the IT, or the processes, or the checks and balances we’ve put in place creating multiple handoffs, or generally a mixture of all of the above. So, we’re back to changing processes or introducing new tools or ways of working, but we’ve already said that doesn’t help, right? No.

Changing the tools or processes is absolutely the right thing to do, BUT, we have to really understand why we are doing it. Equally investing in people and training them is absolutely the right thing to do, but, we can’t solely make it all about upping productivity, because that forgets the people who are at the heart of getting things done, treating them solely as resources rather than individuals with thoughts and feelings. By telling people we’re trying to improve productivity we make it sound like they are not already being productive. By imposing change on them to simply improve productivity we are treating them like cogs in a factory and demotivating them before we even start.

Instead we need to talk to them to really understand the problems they are facing, and what blockers or issues they are having to work around to do actually their job. We need to consider their views and ideas and involve them in the process of making any changes. By empowering our people to talk to us about the issues they are facing and consulting them we are hopefully getting them motivated and invested in any changes we make, rather than making the change happen to them we are doing it with them.

We also need to look wider than one particular function or area, it’s likely that what looks like a productivity issue in one function, is actually a more systemic issue. By just trying to improve productivity in one area we are not considering the design of the whole service, but instead working ourselves into a silo.

While we may have assumptions about what changes will work, we we have to accept we may need to try out different options to really improve things, and we have to acknowledge this out loud. Again, it’s important to manage everyones expectations so that people don’t feel disempowered and like the change is happening to them.

And finally we have to reassure people that we know that for a short period of time productivity will drop and that is ok. And you know what? It is ok. Yes, we all have targets to hit, but if for 2 or 3 months every case worker out there processes 13 cases rather than 15, that is acceptable, because within 12 months’ time, if we as change leaders have done our job right, they’ll be processing over 20 cases rather than 15. And they’ll feel listened to, they’ll feel supported, and in the end productivity will go up.

But it’ll be a biproduct of successful change. We’ll have taken people with us, we’ll have learned from the work we have done, and probably given ourselves a nice backlog of things we can do to keep improving things, so that productivity can keep improving; but more importantly our organisation will hopefully be a better place for everyone in it.

So please, next time you hear a senior manager say “My focus is improving Productivity” just ask them how? And if you are that Senior Manager, ask yourself, “Why?” What is the problem you are really trying to solve? Is it really just about productivity?

We need to lead people, not simply manage productivity.

Originally posted on Medium

Speak Agile To Me:

I have blogged about some of these elsewhere, but a quick glossary of terms that you might hear when talking Agile or Digital Transformation.

Agile: A change methodology, focusing on delivering value as early as possible, iterating and testing regularly.

Waterfall: A Change methodology, focusing on a linear lifecycle delivering a project based on requirements gathered upfront.

Scrum: A type of Agile, based on daily communication and the flexible iteration of plans that are carried out in short timeboxes of work.

Kanban: A type of Agile, based on limiting throughput and the amount of work in progress.

The Agile Lifecycle: Similar to other change methodology lifecycles, the agile lifecycle is the stages a project has to go through. Unlike other lifecycles, agile is not a linear process, and products or services may go around the agile lifecycle several times before they are decommissioned.

Discovery: The first stage of the agile lifecycle, all about understanding who your users are; what they need and the problem you are trying to fix. Developing assumptions and hypothesis. Identifying a MVP that you think will fix the problem you have identified. Prioritising your user needs and
turning them into epic user stories.Akin to the requirements gathering stage in Waterfall.

Alpha: The design and development stage. Building prototypes of your service and testing it with your users. Breaking user needs and Epics into user stories and prioritising them. Identifying risks and issues understanding the architecture and infrastructure you will need prior to build. Akin to the design and implementation stage in Waterfall.

Beta: The build and test stage. Building a working version of your service. Ensuring your service is accessible, secure and scalable. Improving the service based on user feedback, measuring the impact of your service or product on the problem you were trying to fix. Can feature Private and Public Beta. Akin to the Testing and development stage in Waterfall.

Private Beta: Testing with a restricted number of users. A limited test. Users can be invited to user the service or limited by geographical region etc.

Public Beta: A product still in test phase but open to a wider audience, users are no longer invited in, but should be aware they product is still in test phase.

Live: Once you know your service meets all the user needs identified within your MVP, you are sure it is accessible, secure and scalable, and you have a clear plan to keep iterating and supporting it then you can go live. Akin to the Maintenance stage in Waterfall.

MVP: The Minimum Viable Product, the smallest releasable product with just enough features to meet user needs, and to provide feedback for future product development.

User Needs: The things your users need, evidenced by user research and testing. Akin to business requirements in Waterfall and other methodologies.

GDS: Government Digital Services, part of the Cabinet Office, leading digital transformation for Government, setting the Digital Service Standard that all Government Departments must meet when developing digital products and services.

The Digital Service Standards: https://www.gov.uk/service-manual/service-standard 18 standards all government digital services should meet when developing products and services.

Service Design: Looking at your Product or Service holistically, keeping it user focused while ensuring it aligns with your organisation strategy.

User Centric Design (UCD): The principles of user centric design are very simple, that you keep the users (both internal and external) at the heart of everything you do. This means involving users in the design process, rather than using ‘proxy’ users (people acting like users), you involve actual users throughout the design and development process. Recognising different users (and user groups) have different needs and that the best way to design services that meet those needs is to keep engaging with the users.

Why it’s ok to recognise that not everyone is the same.

At our LGBT* AGM a few weeks ago there were some really good conversations about what we could do to keep growing our network and supporting both the LGBT* members of our organisation, and ensuring as an organisation we are recognising what good looks like in terms of care for LGBT* people, and how we can best collaborate with other networks to support each other.

One thing that came up, that I’ve heard a few times before, is that, when talking to people outside of the network, the answer “I treat everyone the same” is thought to be a good answer when we ask care providers about the services they offer people.

Is that good enough? Are everyone’s needs the same? How do we work with service providers to explain why treating everyone as if they are the same isn’t necessarily the right thing to do. Do we understand why it isn’t?

Kylie Havelock does a great session on Equality vs. Equity that really helped me understand the issues we face when we strive to ‘treat everyone the same’.

The fundamental issue is that when we talk about treating everyone the same, we are often taking about treating everyone like what looks good to us. So, by deciding what good looks like for everyone else, we’re often approaching the problem from the point of view of our own privilege and what we think everyone needs based on our own assumptions and life experiences.

The intent is good, but the delivery is flawed. If we don’t take the effort to understand where someone else is starting from, and what they need, then we can never ensure we are treating them in the way that will most benefit them.

If you search online there’s a few pictures out there that help sum up the difference between Equality and Equity. To put it simply, Equality is where we treat everyone the same. Which assumes the same thing will benefit everyone in the same way. Equity is treating people fairly, looking at what they need to ensure they have access the same opportunities.

The photo below is fairly famous now, or at least the one you have probably seen the most if you’ve been following the conversation about Equality and Equity.

By treating everyone the same we ignore that the individuals in the picture are all different heights, so giving each a box to look over the fence isn’t actually very useful. The tallest person can already see fine and doesn’t need help. The middle person can now see with the aid of the box, but the smallest person still can’t see.

By treating them fairly we give each the help they need. So, we don’t give a box to the tallest individual, as they don’t need it. We give the middle individual one box, so they can see, but we then give the smallest individual two boxes, as they had the most height to make up, and they can also now see over the fence. Which is great.

Interestingly the above picture has its own issues, simply because it suggests that some people just need more of the same help than others, rather than the fact that for some people you need to think of a different approach to your solution.

To put it simply, not everyone can stand on a box, and ignoring that fact means we can spend a fortune investing in boxes to ensure everyone can see over that fence, but in reality we are still not recognising what people might need to ensure equal access. So yes, some people might not need a box at all; some might need one box; some might need two, but others might need a ramp, or if they are visually impaired they might need someone to describe what’s happening on the other side of the fence.

(Credit to: http://muslimgirl.com/46703/heres-care-equity-equality/ )

In a business setting, talking about fairness vs. sameness can be beneficial, especially where people have recognised there is a problem. But sometimes you need to go a step further and help people understand why what works for them isn’t what works for everyone, and that can be a little bit tougher, as that can take a conversation about understanding their own privilege.

In my experience, privilege seems to have become a dirty work, as soon as you try to talk to some people about it, they immediately become defensive, because they assumption is made that you are accusing them of intolerance of some kind.

But the truth is we all have some level of bias based on our own upbringing and experiences. Within the civil service and the public sector we have training to help us deal with unconscious bias, but I think we could go one step further with that training and get everyone to understand their own privilege, and where they are starting from in communications or day to day life in comparison to others.

In some areas we will have more privilege, in others we may have less. Understanding that helps us to understand where others are coming from and can then help us to treat people more fairly, rather than simply treating everyone the same.

If you’ve never examined your privilege there are some interesting tests out there, whatever score you get, the questions alone might help you consider things you’ve never considered as privilege before (be that your race, your ability to afford prescriptions or whether you’ve ever had to hide any elements of your identity.) While there are probably better ones out there, this one on buzzfeed is quite simple and easy to understand for a start.

I got 53%, which if I’m honest surprised me a little, I’d assumed I would get a slightly higher score. But the important thing for me is recognised those areas where I did score a point, and reflecting on those when I’m dealing with others to ensure I am being fair to them and not just treating them how I would expect to be treated because of my own privileges.

For those of us in diversity equality groups, when talking to others we need to check our own privilege, find common ground to start a conversation from, and recognise that as children we’re are often told to “be fair and treat everyone equally” now we just have to be able to help people recognise that Fairness and Equality are not the same thing, and it is important that we can all recognise that.

And when designing or delivering public services, it’s always worth us understanding our privilege, and why we need to ensure the services we delivery are fair and give equal opportunities to all those that may need them.

Originally posted on Medium

Making a change or making progress.

At a leadership conference recently there was an interesting debate about whether people perceived making a change or making progress to be more important.

Everyone on my table voted for making a change, my vote initially was for making progress, and so we debated what the difference was.

For me, change can be positive or negative. A negative change isn’t necessarily bad, you can learn from it, but it won’t necessarily move you in the right direction. If you don’t know what outcome you’re looking to acheive or how you will measure whether the change has had the effect you want, how do you know if the you have delivered value or not. There is little value in making changes just for the sake of it.

Progress to me means you are moving in the right direction, towards the outcomes you are looking to acheive. It can be slow, or achieved in small increments, but it is always valuable.

But both good changes and delivering progress both depend on you knowing the outcomes you are looking to achieve, and in my experience that is where organisations tend to struggle most.

They can say what they think the problems are, recognise that things are right, and be willing to make changes to help themselves make progress, but a lot of the time the changes are superficial, offering what are thought to be quick solutions to what are actually much deeper problems, and so the progress is slow and painful.

To transform an organisation and the services it delivers requires a massive change in how the organisation is structured, and more importantly how it thinks.

In my experience this change often starts within Digital, because the organisation views its technology or digital teams as not delivering. And yet the teams can not deliver because the organisation can not express the outcomes it is seeking to achieve or understand the wider problems it is seeking to fix.

This is why user research and business analysis are so important. Why we run Discoveries and encourage service design approaches that span the organisation as a whole, rather than remain within the silos the organisation has structured itself into.

These conversations can be uncomfortable, they challenge hierarchies, organisational structures and traditional assumptions, but they are there to help. Service Design and Product Management is about fostering and supporting those people able to lead those critical conversations, creating the environment we need to deliver outcomes for users and value for organisations.

Being transparent about what the real problems are, and open to new ideas and approaches at an organisational level is key if we want to change and adapt in order to make progress.

When looking to make changes its important to consider the environment we are working within. No conversation is best done via board papers or email, it is best done in the room face to face.

If we can’t move to a culture that values the time and commitment it takes to have those conversations then we must acknowledge that any progress we make will be slow and painful and not deliver any real value or acheive the outcomes we were looking for.

But for all that, recognising that change is needed is the best first step. Stepping up and admitting there is a problem that needs fixing in order to allow you to make any progress against the outcomes you want to acheive is not always easy, but it is important and something we should talk about more.

Needing to change doesn’t mean you have failed or not made progress or delivered no value. It just means you have learnt from what you have done, and recognise there is still more to do and we should celebrate that and talk about it more positively.

Originally posted on Medium

Theme vs. Epic vs. Feature vs. Component vs. Story

Probably the question I get most (after what is Product Management, and what is the difference between a Product Manager/ Product Owner/ Delivery Manger)… ok so the third most common question I get asked is “what I mean by Epic/ Theme/ Feature, Componant or Story, what is the difference?”

And given I get asked it so regularly I thought it was worth sticking my thoughts down in a blog, so that I can call upon it in the future for reference, but also so I can understand whether I’m using them differently to others.

Theme:

When I tall about a theme, I mean something like Accessibility. It weaves through pretty much all stories as a thing we need to consider, will be key in multiple epics, but is not a deliverable ‘chunk’ of stuff on its own.

Epic:

When I’m talking about Epics I’m talking about things like Payments. These are tied generally to a specific outcome or high level user need or part of the journey or process someone takes in using the service. “As a business I want to be able to pay my staff so that they are remunerated for their work” for example. All the stories within an epic are related to delivering that outcome, the stories collected in an epic deliver value together, but the Epic is too big to do in one sprint. An Epic may be made up of several Features, or it may not. If it contains several Features you may prioritise all the “must have” stories from the epic to deliver together, and come back to the “should’s and could’s” later. Or you may save up the stories to deliver all the stories together in one larger release.

Features and Components:

Sticking with the Payments analogy, given the scope of that Epic is large, it would probably contain several features and componants. a Feature would be something like your payments engine, a collection of stories you have to develop and deliver together to release value, whereas a Componant is generally something you can plug in like Bank Wizard. Neither of these things deliver the full outcome required, which is why they are not an Epic.

Just because you can physically pay someone doesn’t mean you can calculate the right payment for example, there will be other stories to allow you do that, all of those stories would sit within the Payments epic as you need them to meet the outcome you’re looking for, but would be developed separately to your payments engine or allowing you to plug in bank wizard.

Finally there are the stories and tasks that are fundamental to delivering everything:

Stories are the individual bits of ‘stuff’ you are trying to deliver. And the tasks are the actions you will undertake to deliver the story. So “as a manager I want to stop payments to members of staff who have left the business so that I’m not paying the wrong people” is a (terrible, sorry) story. It would still sit within the Payments epic, could possibly be part of a feature, but it meets an individual user need. The story would need to meet accessibility criteria, and there are several tasks you’d have to do to deliver it, develop a prototype or speak to stakeholders etc.

Originally posted on Medium

My user manual:

A user manual is a document that tells users how to use a particular system. More recently personal user manuals that help others work with you better have begun to spring up.

I’ve seen a few great examples of personal user manuals recently, most recently from Dan Barrett, and I really like the idea; Unfortunately I’ve never had the time to sit down and draft one.

As I approach the end of my current role and prepare to start at somewhere completely new, I thought it was a good time to reflect on myself, and what it might help others around me to know.

Conditions I like to work in:

  • I like open plan offices, but every now and then I will need a day working from home or a quieter office where I can focus and recharge.
  • I have a high tolerance for background noise, but I don’t like harsh or unexpected noise; similarly with lighting, harsh lighting can give me migraines. •I’m not a fan of hot desking, I prefer having a desk I know is mine. Even when visiting other offices I will always default back to the desk/s I normally sit in. In my office you can always spot my desk as it will have my lego name plate and some bobble heads on it. This may seem odd, but it helps me feel ‘in control’ even when evening else keeps changing.
  • I do enjoy a good workshop, especially if it has post it notes and sharpies, but I’m less of a fan of traditional meetings.
  • My favourite environment is sat with my team, where we can discuss and share what we’re doing, solving problems and achieving things together.
  • I enjoy working in fast paced environments, I’m best when I’m busy and getting things done.

The times/ hours I like to work:

  • I don’t work Fridays, there will generally be an hour or two where I catch up and respond to emails, but Friday is my day for sorting out all the things I need to at home so that at the weekend I can give my son my full attention.
  • I’m usually in the office by 9:30, but I’ll log on at 8 am and start responding to emails and calls on my commute in. I generally leave the office by 4:30, but will answer emails up till 5pm, and then usually log back in for an hour or so once my son goes to bed.
  • For childcare reasons I have one day a week I can’t travel far and tend to work from home or finish a bit earlier, but I balance that by having one day a week I can stay over night or work late.
  • I have the most energy late morning or early afternoon.

The best way to communicate with me:

  • I generally respond quickly to text messages or WhatsApp. •Twitter DM’s are ok, but if I don’t follow you I probably won’t spot DM requests.
  • I don’t like ringing people, and prefer to only answer calls from people I know.
  • I’m not a big fan of emails, especially not long formal email chains. I respond best to quick and easy requests that I can deal with on the move. If it needs proper consideration it will probably have to wait until I have time set aside to be at my desk.
  • I much prefer informal conversations, and respond best to people coming and talking to me. If I’m in an open plan office I’m always interruptible unless I have my headphones in, at which point leave me a note and I’ll come find you when I’m ready.

The ways I like to receive feedback:

  • I prefer feedback one to one in person, rather than in a group.
  • I’m trying to be better at receiving positive feedback and not being embarrassed/self-deprecating,
  • I do like written feedback especially if it’s constructive or critical feedback so that I can properly reflect on it and refer to it, but positive feedback is good in writing too so I can save it and share it with my manager, or with myself when I need a boost.

Things I need:

  • I need to know I am empowered, I need to feel trusted and given autonomy.
  • But I also need to feel supported, I need to know where to go when I need help or just to talk something through.
  • I need to have open conversations, both in a group and one to one.
  • I need big messy problems to solve.
  • I need to be doing things that matter, that are helping people.
  • I need the opportunity to coach and support others, especially when I’m not hands on with a project as it helps me feel like I’m still helping others.
  • I need to have the time to go to events and network, these help me recharge.

Things I struggle with:

  • Putting my thoughts down coherently or capturing action points etc. I’ve worked hard to improve my written and organisational skills, but I know they are not my greatest strengths. When asked for written briefs etc I do better when I’ve got the chance to run it past someone else before submitting. When it comes to organising things, I tend to surround myself with those who are better at it than me.
  • I can find conflict draining, especially if it carries on for a long period. When dealing with conflict I need to be doing something else at the same time where I’m working with ‘my tribe’ and achieving results positively.
  • My memory isn’t great, and I’m usually balancing a lot of things, so if I forget something, do remind me.
  • Delegation, I’m trying to get much better at delegating, but my tendency will always be to protect those working for me, so I need to be reminded that people want me to delegate so that I don’t feel like I’m putting burdens on others.
  • I struggle with unnecessary hierarchy or process. I find it frustrating to explain the same thing over and over again.
  • I struggle to initiate conversations, and I’m not great at small talk with people I don’t know, but I do love talking to and getting to know people.
  • I’m not always great with connecting names to faces, even of people I know, so please don’t be offended if I need a reminder.
  • Talking at people, conferences/ events/ even large meetings are hard for me, but having one or two friendly faces makes all the difference.
  • Eye contact, it’s not you, it’s me. I am listening and I do care. The same with fiddling or doodling. It’s how my brain works, please don’t take it as a sign I’m not paying attention because I am.

Things I love:

  • I love coming up with ideas and solving problems •I love working with a team or one or two others.
  • I like making people laugh
  • I like feeling needed
  • I love building teams
  • I love making a difference, and improving things for people.
  • I love getting to know people, what their interests are, what makes them tick.
  • I love to smile.

Other things to know about me:

  • I am neurodiverse, Dyspraxic with ADHD and Dyslexic tendencies; things like eye contact, doodling, memory etc are all part of this. But I’m good at thinking outside of the box and approaching things from a fresh angle.
  • I am incredibly loyal, if we are friends/colleagues I will always have your back, if you need help I will always do my best for you.
  • I am adaptable and resilient, I will always try to keep going and be flexible in my approach in order to deliver the right thing. I’m good in challenging situations. I get things done.
  • People don’t always think I’m taking things seriously, but I’m very committed and passionate about what I do, I will take on the toughest situations, but I’ll do it with a smile.
  • I’m a people person.
  • I’m a ridiculous extravert and a massive geek, I recharge by spending time with my tribe.
  • I’m a single mum to a neurodiverse child, I work hard to balance my work and home life, and talk openly about the challenges of that in order to support and encourage others to do the same.

Me in a nutshell:

I like to think I fight for what is right, helping others and using my networks and skills to solve problems, just like a certain lady detective. But obviously with less murders and less fantastic outfits.

The Honourable Phryne Fisher

DWP videos

To celebrate Ada Lovelace Day our colleagues share how they’ve been inspired by Ada and other influential women in tech & digital.
In this video Zoe Gould and Arunan Thaya-Paran from DWP and other colleagues from across government give their reflections on the day and the wider theme of why collaboration is so important.
Building the Product Manager Community across Government