The biggest backlog I came across contained around (!)3500 items… I can’t imagine a product owner or a team who would really understand what’s in it.
It kept me thinking – why did it happen in the first place? One of the conclusions was, that product owners, not wanting to say ‘No’ to their stakeholders, say ‘Not now’ and add their requests to the backlog. Realistically, most items in the backlog never get done, but the loss aversion bias prevents us from getting rid of these requests. So the backlog keeps growing.
Short term result is good – the product owner does their job and documents the request for later, the stakeholder is informed that it might take some time to deliver the request, but it can be done, the team carries on with what they were working on. Everyone happy.
Well… There is a dark side of this approach.
Usually, the backlog (a.k.a demand) grows faster than the capacity of the team. This means:
the number of items in the backlog grows, so simple tools might not be good enough to provide a backlog for the team anymore
backlog grooming sessions are now longer and/or more frequent
stakeholders wait longer for their requests to be delivered (partially because the queue is longer, and partially because the team is busy grooming the queue for longer or more often)
some new requests jump the queue because they are small, which makes the waiting time for older backlog items even longer
some work becomes super urgent (deadlines!), which means the developers need to drop everything they were working on and switch the context to the urgent thing
rushing to complete the code leads to low quality and technical debt
stakeholders subconsciously start counting time from the moment they hear ‘it’s in the backlog’, so they are going to get frustrated at a later stage when they discover that their request has not been picked up yet
Less is more
Have you noticed, that most restaurants don’t accept more customers than they can serve at any given time? In some cases, they advise on a waiting time. If it’s reasonable, some people wait, but a lot of them will simply go somewhere else and still have a good time.
Your stakeholders might not have an option to go somewhere else though. Managing their expectations is even more important in this case. It’s more difficult compared to ‘Not now’ but always works better in the long term. My advice would be to try working with the stakeholders at this point and decide together on what’s the most important thing to do. Agree on a limit for the number of backlog items and if there is something which is more important than other items in the queue – remove a backlog item that is least important at that time. A nice trick here is to exchange a number of tokens between the team and the stakeholders. A completed request = a token returns to the stakeholder and there is a space for a new request.
A thought experiment
What if there was no backlog at all? Imagine this:
every time when the team completes work, there is a negotiation with the stakeholder on what’s the (one) most important thing to do next
there are no backlog grooming sessions
there are no extra tools needed for managing the backlog
there is no jumping the queue problem, as there is no queue, the team already works on the (one) most important thing
lead time (time from the request till delivery) and cycle time (actually delivering the request) are the same
there is a slack in the system (and there is nothing wrong with people not being 100% utilised!)
But is it possible to not have a backlog in real life?
Probably not, but trying to reach a great goal which is not possible to reach, still leads to improvement.
So, dump your old backlog and start afresh. Keep it short. Delete stuff. Important requests will always bubble up. Not important ones will go away.
On many occasions, words are not enough to explain a complex concept. And even if they seem enough, you might discover that if you sketch your thoughts in a meeting, you and your colleagues are not on the same page at all.
No, you don’t need to be an artist. If you can draw a rectangle, a circle and an arrow – you are in! The good news is, there is no right or wrong way of doing it!
Some say a picture is worth a thousand words, but I think there are some other good reasons:
this approach lets you step back and look at the problem conceptually before diving into details
if you are already talking details, you can then find connections that were not so obvious to start with
it helps everyone align and spot major thinking flaws sooner rather than later
you remember the details of the meeting for longer
drawing during the meeting makes you pay attention all the time (no daydreaming 🙂 )
Sometimes, when I am acting as a facilitator, I draw the key thoughts on a whiteboard before the meeting, so it helps me remember what I want to say and it helps other to remember that later. Win-win.
This week, I was pitching a concept of a lean organisation. A good representation of what I wanted to talk about was… a pipe. No artistic drawings, just a couple of circles and arrows. This helped me explain why aligning a number of development teams, is important for a large software platform. It worked perfectly.
Giving and receiving feedback is a difficult task but it is also extremely important for any team. For a while I didn’t realise that giving feedback that wasn’t good enough, might actually be pointless or even lead to frustration.
There is an excellent team exercise that illustrates the case.
Sit a team member on a chair and give them a set of tennis balls (the more the better).
Place a bucket behind the person (best at an angle), so they can’t see it.
Ask the person to throw the balls behind them one by one (without looking), so the balls end up in the bucket.
Now, consider following scenarios:
Scenario 1: The person gets no feedback at all, but is still expected to place the balls in the bucket.
Scenario 2: Very negative feedback (i.e. ‘that was useless!’) is given when the balls miss the bucket.
Scenario 3: Very positive feedback (i.e. ‘well done, keep trying!’) is given even when the balls miss the bucket.
Scenario 4: Constructive feedback (i.e. ‘a little bit more to the left’) is given at any time.
Now ask the person how did it feel.
In Scenario 1, it’s a pure lottery. The person does not have any chance to improve.
Scenario 2 is actually very frustrating. The person is trying hard but the effort is only criticised. If you try that for long enough, the person might get annoyed and refuse participating further.
Scenario 3 is not much better. It is definitely motivating but not helping. Giving only positive feedback is not enough to improve!
Scenario 4 illustrates the best way of giving feedback – informative and honest. Feedback that will help adjust next steps, so eventually the goal can be reached.
From now on, I am going to ask myself before giving feedback – is it going to help the other person or is it just words?
This type of retrospective is great for teams working on a new product with a given deadline. The idea is simple – just imagine that the launch date has come and the product… failed miserably. Yes, imagine you failed.
It’s important to imagine it in great detail and capture all possible problems, even if they seem unlikely to happen, they are outside your control or just seem silly. Ask people to get super creative, the sky is the limit here.
I was surprised how quickly my team generated so many post-it notes with potential problems written on them, that they didn’t fit the designated box and we had to double its size.
For a moment we completely lost the confidence in the product… We knew the deadline was tight, but it still seemed doable (before). Looking at the board covered completely with potential problems was an eye opening experience – yes, there is a chance of failure…
Luckily – there is still some time left and there are things that can be done to prevent or mitigate the issues.
We started from grouping the problems into themes.
Having stakeholders participating in the exercise turned out to be very beneficial, as the dev team focussed mostly on technical issues and less on the business side of things. The success of the product is however a complex thing and stable software is just one of its factors.
After grouping all the problems into themes we discussed which of them are real show-stoppers and which are likely to happen. We also excluded the ones we don’t have any control over and focussed on remaining issues.
It turns out that there are quite a lot of things we could do to mitigate the risk of failure. We have generated a list of actions and scheduled some of them to happen really soon, i.e. meeting an expert in the area of where the product is going to be used. Other actions will rather be ongoing – i.e. ensuring a fast feedback loop by engaging in all sorts of activities with potential business users.
You’ll uncover potential problems, which might have been a taboo till now.
Proactive approach mitigates the risk of failure.
Stakeholders manage their expectation better by understanding the technical challenges better.
Dev team understands the business perspective better and how critical their work is.
Attitude to failure
I believe in being proactive, but I’d like to stress here, that avoiding failure is not the point. Paraphrasing Matthew Syed from his excellent book titled ‘Black box thinking‘ – we need to change the attitude to failure. Stigmatising failure will lead to fear and might blind us to bigger problems. Failure is (!) good. So, fail fast and learn fast!
Product Owner is a complex role. It includes aspects of other jobs – there is a bit of being a business analyst, a project manager and UI/UX designer. Product Owners are often involved in very technical conversations and very high level business meetings. That makes the job very interesting. On the other hand – Product Owners can struggle with managing their time efficiently, as there are too many resources competing for their attention.
One day I decided to analyse how can I better protect my time.
Start from data
I started from analysing the past 10 weeks of my work. Where did the time go every day? This was a shocking discovery – every week I was spending in average 20 hours in meetings. That’s half of the time at work! This is how my calendar looked like almost every week:
It wasn’t just the number of meetings, it’s their timing that made using the remaining ‘free’ time difficult. Having just half an hour break in between meetings is not enough to get work done – by the time I get ‘into the zone’, I need to go to another meeting.
Meetings should be like salt
Repeating after Jason Fried, the author of the book titled Remote:
“Meetings should be like salt – a spice sprinkled carefully to enhance a dish, not poured recklessly over every forkful.”
I absolutely love this quote and think about it every time when there are 10 or more people in a meeting.
Where else was my time going?
Meetings were definitely the biggest factor causing a problem, number of emails came second, followed by something I call ‘other people’s agenda’ and ‘just a quick question’.
There is nothing wrong with all the above (communication is very important after all), but if they happen randomly during the day, they might devastate productivity. And this is what was happening in my case.
Before brainstorming ideas for improvement, I set myself a few goals:
Reduce time spent in meetings by 25%.
Reduce context switching to 4 things a day.
Increase focus time to 12 hours a week.
I came up with a lot of potential solutions, but introducing all of them at once would be difficult. Instead, I picked a few and decided to trial them for 4 weeks.
Solution #1: Meetings limit
The new rule says: no more than 3 hours a day, alternatively – no more than 15 hours a week spent in meetings. Also, if anyone asks me when I am available to meet – the answer is ‘Next week’. Before, I used to look for the very next available spot in my calendar.
It’s surprising how many problems can solve themselves within 7 days!
Solution #2: New desk setup
Having collocated dev teams, sat just around my desk makes the communication between us super easy. It leads however to a lot of ‘quick questions’ and other interruptions to which I can’t say ‘no’, as by definition, Product Owner should be always available to the team.
So what can I do to get less interruptions? I have found myself a new desk. This is my ‘backup setup’ (a proper one, with secondary monitor etc.). It is in a different building, where I am surrounded by people from a completely different department, so they have nothing to discuss with me. Just to be very clear: I am there to focus, I am wearing big headphones, which minimise the background noise. I’ve also joined Spotify which offers great selection of ‘Focus’ music (‘Productive Morning’ is one of my favourites).
Solution #3: Focus blocks
This requires a little bit of planning in advance. I am scheduling 4 blocks of time, 3 hours each, in my calendar for the following weeks. The calendar shows that time as busy, so it stops (some) people from booking their meeting as soon as they see a free spot in my calendar. I spend this time in my secondary location, trying to dedicate this time to just one subject.
Solution #4: Email batches
Emails are the main reason of context switching, even if they don’t require any reaction. I realised that having Gmail constantly open in one of the Chrome tabs, I kept switching between what I was working on to emails all the time.
Not any more. The Gmail tab is not open at all. Instead, I have Google Mail Checker Chrome extension installed. A new icon, just beside the search bar is informing me about the number of unread emails. I am ignoring it until it shows at least 10 new emails, only then I am allowing myself to open Gmail.
There are a lot of other little things that can help manage a large number of incoming emails. The following list is for Gmail, but other clients might have similar features:
Labels – they are visible on the list of emails and flag emails meeting certain criteria, for example emails sent directly to you or to a specific group of people.
Filters – useful for unimportant notifications that can go straight to Archives, skipping the Inbox.
Archiving emails – Inbox is not a bin, so keep it lean and archive all emails that don’t require attention any more. This way the Inbox becomes a to-do list. On an ideal day this list is cleared to 0 by the end of the day.
Muting email threads – if an email conversation does not require you any more – simply mute it. Any more emails in the thread will be archived skipping the Inbox.
No invite notification – if you are the one setting up a meeting, you will be getting notifications every time when one of the attendees accepted or declined the meeting. Just turn it off, if someone can’t come to your meeting they will most likely contact you directly.
Solution #5: Calendar setup
I want my weekly calendar to be so obvious, that a 1 second glance at it could tell me my schedule, without a need to drill down into meeting details. There are a few little things that can make a big difference:
Colour coding – every main stream of work (i.e. every team I work with) has a fixed colour, so meetings dedicated to each of them are coloured ‘their’ way. This helps me to instantly know where my focus is going to be and I can spot difficult days, when my attention will be spread across many different subjects.
Hide declined meetings – if I already decided not to go to a meeting and therefore declined the invitation – it should not make an extra noise in my calendar.
Fix working hours – you can set your working hours, so anyone who tries to invite you to a meeting outside this time will get a warning. I’ve set mine to core hours only (10am-4pm), even though I work more than that.
Hide weekends, morning and evenings – why waste space on your screen for times which will never show anything?
Merge meetings – when viewing other people’s calendars, same meeting is shown multiple times. This plugin merges them into one, which improves visibility.
Solution #6: Trello board
Among of other good tools, I am using Trello. It’s great for managing to-do lists in a simple, yet powerful way. The improvements of my default Trello setup I made:
Categories of work – my ‘to-do’ list is now represented by multiple lists – one per main stream of work (so 5 lists including ‘Other’). Every card is colour coded (using Trello labels) according to the stream colour (following my calendar and emails). There is also one ‘In progress’ and one ‘Done’ list.
List limits – keep the lists short, like you would on the kanban board. There is a good Trello plugin that will help by colouring the list in bright red if you are over the limit and in orange if you just reached the limit.
Count cards on the list – this Trello plugin will count cards on the list, so you know how long the list currently is. Helpful for longer lists.
Lists layout – keeping lists short results with a lot of unused space on the screen, as Trello lists are only displayed in columns – one list per column. This Trello plugin helps fitting more lists in the same space.
Ageing cards – it’s a Trello setting. If a card was not updated for a while it will fade, a little bit more every day. That is a good indicator of tasks that might not be that important, like it seemed originally.
Stickers – little images that you can stick to a cards. Useful to flag issues.
Grooming session – like any other backlog, Trello boards need regular grooming. However daunting it sounds, it’s worth doing.
Solution #7: Lab day
This might sound counterintuitive, because I am trying to free up some time, but it’s my favourite. It was inspired by my teams, who spend a day and half every 2 weeks on ‘lab days’. It’s a time when they can work on anything they want in order to improve craftsmanship. They research, try out new technologies and play with the code, which is not related to their daily work. It proved very successful so far – on many occasions people used the new skills to improve existing projects. Why there is no such thing for Product Owners?
I’ve decided to try it too. Once every two weeks (on Fridays), I turn out-of-office assistant on and work from home. I research, write articles, look for conferences or trainings and play with ideas. I’ve only done a handful so far, but it proves very successful already.
How do I know it really works?
It definitely feels better having these solutions in place, but how do I know I am successful?
I’ve set up a short survey for myself, which I am filling out every day before leaving the office. Initially I was only going to do it for 4 weeks, as a trial for the solutions described above. I found it so useful however, that I continue filling out the (modified) form.
Some of the questions on the form:
Time spent in meetings?
Number of focus blocks completed?
Number of [stream name] tasks completed?
Is overtime needed tonight?
Rate productivity (1-5)
Rate happiness (1-5)
I am analysing the data every 2 weeks and decide if any further actions need to be taken.
Reducing context switching increases productivity and decreases frustration.
Small improvements all together might make a big difference in overall efficiency.
Regular retrospectives on daily work lead to continuous improvement.
Improving craftsmanship ensures best quality of the job.
It requires quite a lot of self discipline to stick to all the rules described above.
Software development is not all about the business value, you need to enjoy what you are doing as well. And this is a good idea for a retrospective meeting for an agile team. My team decided to test if there is any correlation between enjoying working on a story and its business value.
The source of data were about 20 completed stories from the backlog put on post-it notes. The very latest completed story landed in the middle of a graph, where X axis represented Enjoyment (did we enjoy the work, was it fun, technically challenging, insightful?) and Y axis represented Business Value (how useful do we feel the story was to the business).
We were thinking in relative terms, so the bottom left part of the graph didn’t mean absolutely no value and absolutely no fun (what Product Owner would allow that anyway?), but the least value and least fun out of all the analysed stories.
Having the first story in the middle of the graph, every other story was judged compare to it – was it more or less valuable/fun?
Having judged the latest completed stories, it was interesting to see where the upcoming stories would be placed. We put them on the graph in orange.
What made some stories landed in the top right corner of the graph? Quoting the team:
Larger pieces of work
Time to get stuck in
Genuinely interesting and novel work
Business value is very clear
Lots of coding involved
Requires creative problem solving
No external dependencies on other teams
Really positive user feedback
Well aligned with the team purpose
A couple of stories landed in the bottom left corner of the chart. Why? Quoting the team again:
Not sure why we are doing it
No feedback or metric that it made any difference
Not much coding – think config changes and software upgrades
Always blocked on other teams
Seemingly simple change but large time investment
Delayed business value – no immediate benefit
Is there a correlation?
We discovered that when the business value is clearly communicated and feedback passed on to the team – it definitely influences the enjoyment rate. It was a very important message to me, as the Product Owner.
There are however other factors that have an impact on ‘being in the zone’ while working. There are some great books about it, to mention just a couple:
This sprint we decided to focus on eliminating waste. At the beginning of the sprint we agreed to a definition of waste: anything that’s not directly related to working on sprint stories. According to this definition – daily stand-ups, sprint planning and retrospective meetings (and any other meetings), refactoring the code, reading manuals, working on support issues or bugs – that’s all waste.
Every day, we were recording wasteful activities on post-it notes, including how much time they took. We were posting them in a central place, building the body of a waste snake.
It was interesting to see how the snake was growing on daily basis. Very quickly there was not enough body in the snake and post-it notes had to cover older notes making the snake fat. At some point we simply moved the tail to get more space.
Before the retrospective meeting, I quickly grouped duplicate notes and summed the total time of the snake. The first task for the team was to estimate how much time they recorded in total. Surprisingly – the estimate was only 30% of the value!
The next task was to group the waste into 5 categories, which didn’t have names yet (except for the obvious one – Meetings!).
Categories the team discovered were as follows:
It turned out that meetings wasted most of our productive time. Support issues were rather a surprise – we didn’t realise that we were disturbed so many times during the sprint (context switching!). Quite an unexpected category from my perspective was ‘Stupid discussions’.
According to the initial definition, learning did not directly contribute to the sprint, but it’s necessary in the long term perspective. We moved all post-it notes like that to a piggy bank. Here we had a little debate – are meetings a waste or an investment? Do we need stand-ups every day?
That left us with with a ‘real’ waste. Could that be avoided? What could we do to stop it happening?
Unfortunately it’s not possible to avoid all of the waste, but there are tricks to mitigate it.
Stupid discussions can be stopped by a Mango rule. Whenever someone feels like the conversation is too much off topic – just stop it by saying ‘Mango!’ (or whatever other word the team would like).
Meetings could be shorter. A standing retrospective we ‘accidentally’ tried when discussing the waste snake – actually made us go straight to the point and we did finish earlier than planned.
Pomodoro technique is a good way of reducing context switching, which is much more costly than it seems – coming back to the ‘zone’ after a distraction might take even 15 minutes!
We also wondered if switching from Scrum to Kanban would help to better use the time. That is still open for a discussion another day.
Waste snake’s goal
That’s important – the goal of this retrospective was not to control the team by understanding how they manage their time, or by recording every single wasteful activity. The real goal was to raise awareness of waste as the opposite of delivering value. There are many ways of using the time more effectively, but the first step is to recognise the need for it.
Some people might be reluctant to take part in this exercise and openly admit to wasting time.
People need a reminder to note things down (I was sending an email every day containing some facts about snakes or a funny picture of a snake. Also, everyone got a print out of a snake).
A little success story
I overheard a conversation when a team member said: ‘Maybe Anna is right and we shouldn’t work on this problem right now – it’s nothing to do with this sprint stories, so it’s a waste’.
To be honest, we don’t do backlog grooming sessions too often. By focussing on what’s at the top, we believe that everything else simply doesn’t matter. Yet.
This down-to-earth approach can get out of control, especially when anyone from the team can add backlog items that need work ‘at some point’. When not watched, this can lead to a fat and ugly backlog over time, where user stories are waiting forever to get done. Seriously – having a small agile team and 100 items in the backlog – do you really believe that item #100 will ever be done?
Knowing our velocity, it would take about 8 months to complete all the backlog items. That is assuming that no new bugs, important requests, or the need to rework an item doesn’t appear in the meantime. In theory, any new request would need to wait 8 months. That’s not very agile, is it?
If in doubt – remove
One day we decided to challenge the situation and leaving just 4 top stories in the virtual Lean Backlog box, we moved all the other backlog items into a virtual bin.
Seeing all the backlog items in the bin came as a bit of a shock to the team at first, and the loss aversion bias kicked in: ‘We can’t just delete the whole backlog!’ the team said. ‘Can’t we? Can you even tell what is in the backlog at the moment?’ – I asked.
Sell it or lose it
The first task of the session was to sell each backlog item to the team, or in other words – prove its importance. Questions we were asking were along these lines:
What’s the real impact of this item?
Who are the stakeholders?
What’s the cost of delaying this item?
What’s going to happen if the item is not done at all?
Can we justify working on this item within next 3 months?
Is this really so important if nobody chased that issue for so many weeks/months?
Surprisingly, we realised, that we didn’t even remember adding some of the items to the backlog, let alone being able to explain them in details. In the end, only 40% of the items managed to get out of the bin. That means – 60% of the backlog items deserved to be deleted!
All remaining items had to go through prioritisation process – comparing business value and development effort required.
This approach, leaving us with a healthy backlog with only essential items, was inspired by company called 37signals and their book titled ‘Getting Real‘, which you can get for free. This is what they think:
Make each feature work hard to be implemented. Make each feature prove itself and show that it’s a survivor. It’s like “Fight Club.” You should only consider features if they’re willing to stand on the porch for three days waiting to be let in. That’s why you start with no. Every new feature request that comes to us – or from us – meets a no. We listen but don’t act. The initial response is “not now.” If a request for a feature keeps coming back, that’s when we know it’s time to take a deeper look. Then, and only then, do we start considering the feature for real.
Done right – either Scrum or Kanban will work for an agile team. As a Product Owner I always leave the choice to the team, even though I do have a preference.
One of my teams, who initially chose Scrum, decided to give Kanban a try. The plan was to try it for a month and then retrospect on what suits us better. Every day we were collecting data in order to make a proper data driven decision at the end of the experiment.
Work in progress (WIP) limits
We already had a WIP limit for number of tasks (7) and decided to keep it as it was. Deciding on SIP (stories in progress) limit was not that easy however. The very first day, the team (of 8 people) automatically picked 6 stories from the backlog and were ready to start each of them(!) straight away. From my perspective they were completely missing the point. Less work in progress means more focus and less context switching, which is a silent killer of good quality. Here is a good video about why limiting WIP works.
We negotiated and ended up with a limit of 4 stories. Observing the team I realised, that there was an attitude change required as well. I witnessed a situation when two team members finished a story and instantly started picking a new story from the backlog, instead of checking with the rest of the team if there is anything they could do to help progress other stories.
NB: WIP limit is a limit, not a target!
We were not excelling in Scrum straight away. It took 6 sprints to deliver exactly the number of stories we committed to in the sprint planning meeting. To be fair, these were very first sprints of the newly created team, so we knew it was not going to be perfect.
What actually triggered the thoughts of a change, was the fact that the team was adding quite a lot of technical stories to the backlog. Some of those should really be part of the original user stories the team was working on. Questioning further, we found out that the reason for separating the ‘user work’ and ‘technical work’ was… the sprint end. The team wanted to mark stories as done, even though unit test coverage (or some other technical aspect) was not good enough. That’s not really a ‘done’ story, is it?
Initially the team kept working on many stories at the same time (orange bars on the chart below). This was making the cycle time of each story longer – very little was being completed (green bars on the chart). As soon as the number of stories in progress went down, stories were completed more frequently and the cycle time (and lead time) got shorter.
Another thing that improved when we switched to Kanban was the number of stories completed (throughput). The data clearly shows that the team started delivering faster than before.
Before deciding one way or another, we dedicated one retrospective meeting (we kept having retrospectives during the Kanban trial) to talk about what went well (or not) and how does the team feel about going ahead.
The new ‘data’ (post-it notes) clearly showed an interest in Kanban.
Some conclusions about Scrum:
End of sprint was causing stress to some team members and resulted in additional technical stories. However, a deadline was a good motivation for others.
Sprints mean predictability, but because we almost never completed all stories that we committed to, it was no use to me as a PO.
Some team members didn’t have anything to do at the end of the sprint, while others were rushing to complete their work (or create a ‘leftover’ story instead).
There are a lot of rules to follow and artificial deadlines.
Every sprint naturally ended with ‘lab days’ – a day and half when the team could work on anything they wanted or simply learn new things.
Some conclusions about Kanban:
We were going faster (which could be also a result of the team maturing).
Kanban is more responsive to changing business priorities, which is great from a PO perspective, but not everyone in the team can embrace uncertainty the same way.
Meetings only happen when we need them, and not because the calendar said so. Stories are groomed as we go along, demos happen when there is something to demo.
Stories are broken down to tasks only by part of the team, which is more cost effective, however perspective of other team members is missed.
Developers can focus on finishing a story, including unit test and any required refactoring, without stressing about the sprint end (let me quote one team member: ‘hack less to complete story on time’).
There is less work in progress.
The team missed their lab days because there was no sprint end.
Some of these points, like WIP limit or lab days, could be enforced in both – Scrum and Kanban, so they are not really related to the framework.
The voting was undisclosed. Everyone simply stood by the side of the wall, which described their chosen framework. This resulted in 5 people standing by Kanban side and 3 people closer to the Scrum side (in between actually).
Something to remember
Before you switch to any new framework – invest some time in communicating again what the change is about. I don’t think it was very clear in our team – we just assumed that everyone knew what Kanban was about. Surprisingly – we weren’t aligned and some people struggled initially.
Experimenting with different frameworks can help the team to uncover some issues, that even though not related to a specific framework, might have been not visible before.
In my opinion, Kanban is more flexible to work with, but requires more self discipline. I’d advise less experienced teams to try Scrum first.
What’s the benefit of user personas? Our most successful persona started working… the same day! Funnily enough, it was a segment we initially missed in our user research.
Albert represents a segment of our internal users who are very costly to the company, even though it’s not the biggest segment of all. Kicking off exactly on the day of introducing the Albert persona to people from outside of our team, ideas for improvement started flowing from everywhere. We discovered very quickly, that with minimum effort, we can help most of the Alberts and save the company quite a lot of money at the same time.
User research first
This is very important. Before creating a persona profile, it’s crucial to do user research. I’d recommend to do both – qualitative (interviews) and quantitive (data) forms of research. The more, the better. And don’t stop just there.
What to include in a persona profile? A lot depends on the actual characteristics, however there are some key elements, which I believe are absolute minimum. These are:
Make the surname representative of a feature within the segment.
High quality photos showing more than just the face and the real environment of the persona tend to work best.
Don’t segment your users based on demographics. User goals are the criterium for it.
Some demographics will however, make the profile more personal and easier to believe (“yes, it’s a human…”).
Not all personas are equally important. Decide on which persona is primary, secondary or excluded.
Quote your persona using the language they would use.
Give examples as opposed to being generic.
Try to fit within 1 page.
Keeping personas alive
Even the best personas might not work if they are not communicated properly. Make sure you keep them alive – you can quote them in user stories within the backlog, display their profiles all around the office or even (like we did) order a life-size cardboard cutout! This might seem a bit strange, but it will definitely trigger a lot of conversations around user centric design.