Posts Tagged ‘visualisation’

noganttMy team were struggling to make their sprint commitments. Sprint after sprint, we’d go into planning, pick the stories that we believed we could finish in the sprint, and get to the end with things not where we wanted them to be. To make matters worse, stories were piling up towards the end of the sprint, leaving testing (and feedback) right to the end. Our best intentions were just not translating into a workable plan and it was hard to see why. And then someone suggested that we try visualise our plan in Sprint Planning 2 (SP02): would it help if we created a Gantt?

My gut reaction (as their Scrum Master) was pretty strong. I had flashbacks to my Project Administration and Project Manager days where my life was ruled by Microsoft Project Plans and unrealistic resource-leveling. I recalled long arguments about how, just because you could get a document through our intensive quality checks in two days, usually, it took about a week, plus you needed some days to rugby-tackle your busy stakeholder into signing it once it was ready. All this meant that your team was (in Gantt terms) “not working” for the duration of the document review task – which was unacceptable when everyone needed to be at a consistent 75% utilisation for the project. Then there were the status reports and percentage complete updates (how do you know you’re 50% complete if you’re not done yet?) and lines that jumped and moved (or didn’t) when your dependencies were mapped incorrectly.

All of the above happened in my head, of course, and we agreed to give the Gantt chart a try during SP02. Thankfully, besides knowing how to draw a basic frame, all my historic experience with Gantt charts meant I also knew which questions the team would need to answer to complete one – plus the mistakes people usually make when creating a visualisation of duration.

Before I share with you what we did, I think I’d better let you know how things turned out. The first few times we did it, people really struggled and it took a while to create the chart. However, with practice, it became just one more SP02 activity, and eventually, I didn’t need to help the team at all.

The visualisation helped us highlight where we were overcommitting ourselves (expecting one person to work on too many things at the same time; forgetting when a team member was on leave at a crucial point; or not finding ways to do some testing earlier). In making our poor planning assumptions visible, it helped the team figure out workarounds before the sprint even started e.g. for very long stories, they’d identify smaller milestones for feedback. Or where they realised that the type of work was very heavily weighted towards a particular skillset, they identified simpler pieces where less experienced team members could pair up and work together saving our “big hitters” for the more complicated stories. We also got better at accommodating sprint interruptions (like public holidays or whole-team-training) and adjusting our sprint forecast accordingly. Lastly, we started taking our Gantt into daily stand-up, and the team would adjust their Gantt plan at the end of stand-up which was a great way to see if we were on track and, where we weren’t, what needed to change.

How did we do it?

This is how we used the Gantt chart. Firstly, after SP01, I would create an empty framework for the 10 days of the sprint. I’d add any known “events” that would impact us, for example:

  • Our sprint ceremonies were on there
  • Any planned grooming slots were indicated
  • Planned leave/training was reflected- with the box size representing whether it was a half-day or full-day
  • Other significant “distractions” were added, like floor release dates
  • Any other planned meetings we were aware of after Sprint Planning 1 (SP01) were added
  • Weekends and any public holidays were blocked out
  • We also made the sprint goal visible on the last day (Review box)

The team would then work down their list of Backlog Items agreed in SP01. After discussing the item and the tasks for the work involved, they would then plot its expected start and finish date on the Gantt. As this was duration-based, in the beginning, I sometimes needed to remind them to add an extra day where a task ran over a public holiday or the person(s) the team assumed would be picking up the task (based on what was going on/availability) was going to be out of office. As they generally had an idea of who might be doing what, durations were also adjusted based on the person doing the work e.g. they would sometimes add extra time if the person was working in a space they were less familiar with. Even without thinking about who would be working on a specific task, the Gantt made it very clear when they were expecting to start more stories on the same day than there were people available to work on them. As previously mentioned, where stories looked to have a longer than usual duration, the team also brain-stormed mini-milestones where testing/checking could happen (e.g. if it was a five-day task, they’d try have something that could be tested/checked every 1-2 days). I added the tasks to the Gantt chart the first few sessions we used it, and once they’d got used to the idea, then a team member started doing it.

Finally, if the Gantt showed we’d been mistaken about our forecast in SP01, it meant we were able to communicate changes to the forecast before the sprint even started.

ganttall


This team had a specific problem to solve. As it turned out, the Gantt chart helped them create a shared view of their sprint plan which could be used to help them test their thinking/approach. It had a bit of a learning curve and took time and energy to create though, so I’d still caution against “just using it” for the sake of it. However, I’m also now likely to suggest a team tries it if they are experiencing similar planning problems to this team.

Have you ever used a Gantt chart for sprint planning? What did your team learn? Or have you been surprised by some other tool that you’d previously had bad experiences with? What was it and what did you learn?

 

I have a new team. It is a fairly large team with varied experiences working in an agile fashion. We’re also still figuring how design fits into our overall value-delivery chain (as an organisation, not only as a team) and recently I found myself having to help clarify some expectations and terminology which had led to some confusion and conflict.

At this point, if you haven’t read these already, I’d recommend you read these two blog posts for some background context:

  1. Change Managing our Backlog Refinement
  2. Overlaying needs, phases and quality concerns

The conversations I had with various team members led to me creating this rough visualisation of what where you are in your Epic and backlog refinement conversations means for the necessary level of granularity of front-end design.

A caveat: I believe there could be a third axis – one for “figure out what the problem is” (Product Discovery), but due to where my team was in the delivery cycle, I left it off to reduce confusion. This scribble assumes we know what problem we need to solve.

UX vs ADKAR

So how does the above work?

The vertical (y) axis represents where your Epic is in its “quality” journey. Are we still just focusing on getting something working (Functional/Reliable)? Or are we polishing a feature that is almost ready for release or is already released (Usable/Pleasurable)?

The horizontal (x) axis represents where in the refinement process we are with the team for the piece we’re hoping to take into our next few sprints.

The colourful blocks (intersections) represent what level of visualisation the team probably needs for their refinement conversation based on x and y. So if we’re just starting on an Epic and want to get to a slice that does the basics for internal testing or Beta feedback (usable) and the team have had a conversation to understand the problem and are starting to think a bit more how to slice the next chunk into pieces of user value (Break-down), then you probably don’t need anything more granular than a wireframe to work with to have the conversation and figure out the next steps. If you’re already bringing pixel-perfect designs into a conversation at this point, there’s a lot of risk that there will be expensive re-work required. There’s also a risk you’ll miss out on a more creative approach/idea because the team will be less willing to suggest changes to something that has already had so much effort put into it. Finally, because pixel-perfect isn’t necessarily required for something usable, having a lower level of granularity (in this example, high fidelity) means it’s easier to make changes when we get feedback from users of the “usable” version of the Epic.

So far I have used this tool to help team members know what they need to prep for a backlog refinement conversation, and I plan to use it when facilitating conversations to the right-hand side of the y-axis so that team members remember that “grooming” isn’t always about ready stories.

Would you find this a useful tool? If you have used it, let me know how it went.

6hatsThis is my take on using “Six Thinking Hats” to reflect on a period of time. You could use a light version for a retro – or the full version to review something longer like the stage of a project or a release. It’s usually most effective after some milestone event and where the learnings can be applied going forward. There is still value in doing it at the end of a project, but what you get out of it for future teams may not be as valuable as you won’t always know what will be applicable.

Preparation

In order to save time in the session, you do need to do a fair bit of preparation. Try and collect as many facts about the time period as you possibly can before the session. Facts are anything backed by data and some common “facts” one might include are:
– Team changes (people joining/leaving)
– Events (e.g. release dates)
– Sprint information (velocity; commitment; actuals; sprint goal; etc.)
– Changes in process
– Special workshops or meetings
– Any data provided by metrics

I’ve found the most effective way to use the facts in the session (and the rest of my post assumes you have done this) is to map them onto a really large timeline. I typically use a sequence of flip chart pages that can be laid out so that attendees can literally “walk the line”. I’ve stuck them up on long walls or laid them out on a row of tables and even used the floor where I needed to.

It is also useful (for the reflectors in the team) to send out a description of the hats in advance and ask them to think about each one before the session.

Before you start your workshop, you have to set up the room (also see the tips at the end of this post):

  1. Lay out your timeline
  2. Ensure there is space for people to easily walk along it
  3. Have various stationary points along the timeline with pens and stickies
  4. Don’t forget to have a whiteboard or some other space for grouping the ideas

Materials

Besides your “timeline” of Facts, you will also need:

  • Small pieces of paper that people can write appreciations on
  • Pens
  • Stickies: one colour per hat
  • *Optional* Snacks

For the different hats, I usually use the following colours

  • Facts: N/A (people write directly on the timeline)
  • Instincts: Red
  • Discernment: Blue
  • Positives: Yellow
  • Ideas: Green

Process

The process I follow is largely based on this one and, as they mention, I have found that the order is fairly important.

For an average team, I time-box each section to about 10 minutes. Breaks need to be at least 5 minutes, but could vary depending on the time of the day (e.g. you may need a lunch break). If you are going to use the data in the session to come up with actions and improvements, then your time-box for that part will depend on what technique you plan on using. Obviously these may need to be adjusted based on the size of the group, but as most of the steps are self-paced, one advantage of this workshop is that it works quite well with larger groups.

Round 1: Facts

Have the attendees “walk the line” from the beginning to the end. This is a walk down memory lane and also a chance to fill in any blanks and ensure everyone agrees that the facts are correct. There are no stickies for this step – if people want to add or change anything they do that by writing directly onto the timeline (at the right point in time, of course). Remember to remind everyone that they should only be adding facts.

Round 2: Instincts

“Gut Feel”

Hand out your “instinct” stickies. Remind every one of the definition of an “instinct”. I sometimes skip this round because people struggle to differentiate between “instincts” and “positives/negatives”.

Appreciations and Break

Give everyone a chance to write appreciations (these will be shared later – either at the end of the session or afterwards). It’s also a good point to have a short break.

Round 3: Discernment

“Devil’s Advocate”

Make sure you’ve collected the “instinct” stickies and that the next colour of stickies is available. Remind everyone what the definition of “discernment” is. Everyone repeats their walk of the timeline, this time adding stickies to the timeline for things that didn’t go well or were disappointments.

Cool off

Have another break (in case things got emotional). Have people write more appreciations.

Round 4: Positives

“Keep doing this”

This is the last walk of the timeline. Again, remind people of the definition of “positives” and ensure there are only “positive” stickies lying around for people to use. They walk the timeline one final time and add stickies for things that went well.

Lastly: Ideas

“If I did it again”

There are various ways to capture and categorise ideas. The intention of this round is that attendees use the timeline to stimulate their thinking of how they could have done things better. Or how they would do things differently if they had to do it again. This is  sometimes also described as “green fields” thinking.

And then (now or later)…

If you were using this technique for a retrospective, you would ideally get actions from the information as part of your session. If the session was to reflect on a project, perhaps the data would be grouped into things like “Good ways to kick off” and shared with other teams. I’m quite a fan of the quadrant method of grouping similar stickies to find topics to address (see photos below for examples from a retrospective I did). What you do next all depends on the ultimate purpose of your session.

quadrants

Tips

  • Only let the attendees have access to the writing materials relevant for the round i.e. gather up the stickies from the previous round and “change colours” for the next round.
  • Have a number of “stationary points” – so that people can grab stickies and pens as soon as they have a thought.
  • Related to the above, have an excess of stationary and pens so people don’t have to wait for each other.
  • When preparing your timeline, try use pictures/symbols/colours to create visual patterns and cues for repeat facts e.g. document your sprint information in the same colour and layout for every sprint on the timeline or have a bug symbol where you have added statistics around bugs.
  • Don’t forget to share the appreciations! Especially if you’ve decided not to do so in the session.

I have applied this technique a couple of times and used the output for various things:

  1. We’ve used it to gather data for a team which was unfortunately not very transparent and then used that data to paint a “real picture” for external stakeholders.
  2. We’ve used it in retrospectives to identify improvements to team / process / products.
  3. We’ve used it at the end of a project to create guidelines and lessons learned for future projects and teams.

timeline

Have you used this technique before? What worked or did not work for you? Where might this approach be useful?

I am currently working with a distributed team and we use JIRA for our sprint task board. We use it in our daily scrum (I can’t call it a stand-up) via Zoom. Over time, I’ve noticed that there are some things that come “for free” with a physical board, but are hidden or not as obviously visible on a digital board (at least not in JIRA). We have found workarounds for some and not for others and, perhaps, depending on the team, not having some of this information “in your face” might be OK. However, I thought I’d make a list of things to look out for if you happen to be using a digital rather than physical board for your team. Also this blog is all about learning 🙂

Please note, I’m only basing my observations on JIRA for this blog post because that is what we use. I suspect that most digital task boards have similar issues.

1. Who’s doing what?

My teams in the past have used personalised avatars to indicate who’s doing what task(s) for the day. We found this had two related benefits:

  1. You were naturally constrained to the number of avatars you happened to have available to you (although it was still fairly easy to take on more merely by initialing the sticky).
  2. It was very easy to see at a glance where a task had too many people, or where one person seemed to have spread themselves to thin, or where someone hadn’t committed themselves to a task.

When asking the question, “what do you notice about our focus?”, it was easy for the team to notice where they may have over- or under-committed themselves for the day. Or to notice and confirm where they were swarming for the day.

In JIRA, only one person can be assigned to a task. It’s not visually obvious where multiple people are working on a task. Also, because we usually only expand the story we’re currently talking about – and usually our full sprint of stories doesn’t fit into the view if we expand all rows – it’s very hard for the team to see good and bad patterns in how they have allocated themselves to tasks for the day.

2. Where are we stuck?

One of the tools one can use on a physical board when it seems a team is taking a while to get things done, is to start dotting tasks. The idea is that a task gets dotted for every day that it has been in progress and not finished. As the task develops measles, it’s pretty obvious where someone may be blocked or may need help.

JIRA does have the concept of task-dotting, but it’s very hard to see (it’s a light gray) and unfortunately the dots don’t stick around. They disappear as soon as someone moves the task to the next column on the board (so, for example, a task that may have been in progress for two days will suddenly have no dots when it moves to the show me column).

When dots have measles, it’s easier for the team to notice where tasks are dragging on for days and do something about it. You don’t really want tasks that have started to take more than a day to finish.

3. How big is our story?

This is probably (hopefully?) a JIRA funny. When we’re viewing the active sprint and sprint board, the story points aren’t visible. Assuming you use story points, they can be useful in helping the team notice when a story is taking too long – a supplement to the burn-down (see below) and tasks with measles (point 2 above). We have a workaround in that we add the story points to the end of the story title. It would be cool not to have to do this.

4. What’s our progress?

JIRA generates a pretty cool burn-down. But it’s not visible on the sprint task-board (which is the view we use for our Scrum meeting). How you’re doing on your burn-down is quite an important piece of feedback for how to adjust your plan for the day. Our workaround is to publish it on Slack before we meet, but it would still be useful to have it visible for the conversation.

5. What’s our goal?

I love (good) sprint goals. I find they give the team something specific to aim for that still allows for creative ways to respond to minor changes that emerge during the sprint. Goals are also a really useful way to bring the team back to the bigger picture in terms of sprint progress: “Are we on track to achieve our goal?”; “What are you doing today to help the team achieve the goal?”. So we create an awesome team sprint goal and ideally we want to have it front-of-mind when planning our tasks for the day. On a physical board, this is easy: it can be as simple as printing your goal on a piece of paper and sticking it to the board (ideally in colour and with sparkles). On a digital board, one needs to get a little more creative. In our case, we write the goal as a story at the top of the sprint and try remember to refer to it before we start our daily conversation. It seems to be working, but it does blend into all the other sprint work.

6. There are other aggregate data questions that are harder to answer

As Jacques de Vos once said: “If you have to scroll, you can’t see the whole“.

With a physical board, the team can usually notice useful things when answering questions like:

  • What do you notice about our tasks in progress?
  • Where do we seem to have the most focus?
  • What do we notice on the board about stories not started?
  • What do we notice about the state of our overall sprint in terms of stories in progress and not started?

Usually a quick glance at how stickies (whether stories or tasks) are grouped in the various lanes of the task board can provide a lot of insight into how things are going – especially if the distribution pattern is looking different to what the team is used to and/or expects to see. With JIRA, this view isn’t easily available. Expanding all of the rows creates a very busy view which is also not guaranteed to fit without the need to scroll. Collapsing the rows hides the task distribution (which may hide other things) and also the story status is represented by a word rather than the story’s location relative to the board’s columns and other stories.

7. There’s usually a driver

The way we use JIRA, someone screen-shares the taskboard in our Zoom session and that person automatically becomes the ‘driver’. What I’ve noticed about this is:

  • People are less likely to interact with the board during stand-up: they’d rather ask the driver to make updates or create emergent tasks
  • Some people are scared to drive (probably a tool thing – either JIRA and/or Zoom), so never do
  • The driver can get distracted by the mechanics of having the right story expanded, or making changes in JIRA, or whatever – so are not always fully present in the conversation
  • If the driver ends up being someone in a “leadership” position (e.g. a senior developer, the Product Owner), then sometimes they subtly control the decisions the team makes in terms of what they plan to do for the day because they can move things or assign things before the team have finished their discussion
  • All of the above means that the negative aspects of “you do it, you own it” sometimes sneak in…

I shared some of these challenges on the #zacoachclub channel in the Coaching Circles Slack Group and got some useful ideas to try out:

  • Write down in detail what information you really need the board to show so that it becomes your information radiator. Then lose all pre-conceived notions of how a board should look and how your tool sets up its boards. Based on the info you need: what could a board in your digital tool look like?
  • Try to represent the info you need in something other than your tool (i.e. JIRA) – maybe Google Draw or something. Once you have something that works, try implement that in your digital tool.
  • If the problem is too many things on the board, could your sprint/commitment be smaller to fit everything in one view?
  • Create a filter that filters out “old” done items and try to only work from the top story (limit work-in-progress).
  • Shift some of the information elsewhere e.g. Say pairs work on the story – they break down tasks in another place (Trello?) and feed back only relevant info to the greater team on the story which is in JIRA. Feedback to their mini team is much more granular and on another board/tool.

Do you use a digital board on your team? What challenges have you experienced? What did you try?

Scrum-Task-Board

StoryMap

(This is part 1)

I liked the idea of story-mapping from the first time that I read about it. I’d done a couple of up-front sprint zero type exercises to create and size a Product Backlog at my previous company, and the feedback from the team about the exercise was that, once it got down to the relative sizing, it was hard to keep a grasp on the bigger picture and people often got confused about the relationships and boundaries between stories.

Simply, a story map is a way of maintaining a visual connection between stories as it shows the higher level user process (which also intuitively maps dependencies in 99% of cases) while showing the stories underneath. The other cool thing is that it’s a visual way to ensure one is doing vertical slices – by choosing stories in horizontal groups (so across the user process). Stories are also prioritised vertically adding the dimension that comes from the traditional Product Backlog. One of my team members, seeing our story map for the first time, described it as a ‘seven dimensional view’ of the project. Amazingly, although it has these many dimensions, it’s a pretty simple view to understand and can also be used to show progress.

If you haven’t already done so, I recommend you spend a worthwhile hour watching this video. I’ve also added some other links about story-maps below, but the video is still one of the best resources I’ve come across.

For this two-part entry, I’ll describe a bit of how our very first story mapping session went and some of the learnings I gained from running it. I intend to do some follow-up posts over time as our map (hopefully) evolves.

Our ‘project’ is slightly challenging to story map as

  1. We’ve already started working
  2. It’s about replacing something that already exists
  3. It’s related to our security architecture – so it’s very technical and quite difficult to map from a ‘user’ perspective.

My session (which ended up being two) followed the approach in the video quite closely, so had the following parts/steps:

  1. An intro in which I highlighted the desired outcomes and high level process that we would be following in the session. I also introduced the goal that was proposed by the Product Owner. This led to some debate as it was more business focused, whereas work to date (about a year) had been more about the technology. The team felt there were other ways to achieve business value using the existing infrastructure (a valid point). In hindsight, the goal may not have been the best goal for the session, but it did result in some much-needed debate and clarification and still helped keep the group focused on business value rather than technical goals. I did receive feedback that more up-front detail on the overall process we followed may have been useful in the intro as people weren’t always sure when it was the right time to introduce an idea/concept (none of the attendees were familiar with creating a story map before the session).
  2. The team (individually – silent brainstorming) wrote up stickies (all the same colour – purple) about the ‘things people do’. To help stimulate their thinking, I put up some typical users (we ended up trashing one of them). I also took them through the email example (just the user task level) to help get them to the right level. Once everyone was done scribbling, they did the grouping and naming exercise as demonstrated in the video. We actually struggled with our user tasks being too high level (e.g. manage xyz) rather than too low-level: it did help to try to get the team to start tasks with verbs where they had to break it down a level.
  3. We prioritised the groups and user tasks from left to right and ran through some scenarios. This highlighted a lot of gaps that hadn’t been clear before. At this point the group were getting quite tired and it was nearing lunch time. If I’d had time, I probably would have given everyone a long break at this point. As it was, we only had time for a coffee and tea break. Until now, all the work had been done on a large table in the centre of the room: I now put the skeleton up on the board (not wide enough) for the next part of the exercise. You need a very wide space for story maps!
  4. The next part was not done as comprehensively as we would have liked. We skipped writing stories for some user tasks that we knew wouldn’t be in our first slice and didn’t get into the detail of the second application we’d identified. We also did not write stories for work that we’d already done, which created some confusion later. We still got what we needed out of the exercise, but more time would have been good, and we will need to revisit parts of our skeleton. There’s also a (low) risk that some of the tasks we’ve left out for now are actually risky/important for our first slice.

That marked the end of our first session as we were already thirty minutes over time. Throughout the session, I encouraged the team to write down issues, risks and assumptions on bright pink stickies so that we could ensure we addressed them appropriately and did not forget about them. It also automatically created a parking lot, because anything that was relevant overall but not to where we were in the process could be parked (and eventually they did all find a home, either on the story map or as impediments in our impediment backlog).

Things that I felt worked well:

  • Being strict about using certain coloured stickies to represent particular things. This also made it easier to reproduce the map in a different location!
  • The email example was useful for framing what level we were speaking to.
  • The individual brainstorming and grouping approaches both worked really well. They got people on their feet and everyone engaged once they got the hang of it.
  • Do try to stick to the recommended 5-7 person limit.
  • The product owner was happy to see the team focusing on a business goal rather than a tech goal.

Things that didn’t work well:

  • We didn’t cover all the scope when we created our stories. We may have missed something.
  • Time. In the end, we needed three-and-a-half hours to complete both sessions (which wasn’t far off my gut feel of four hours).
  • Related to time, the team got tired. We could have done with more breaks.
  • The conversation about and agreement on the goal should have happened before the session.
  • Ideally this exercise should happen before work has started, as having done and partially done stories did confuse matters when creating the map.

Links

A must-watch for anyone interested to learn more about story-mapping and/or slicing and visualising projects/products better.

Story-Mapping Video