Posts Tagged ‘sprint goal’

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:

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).

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…

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?

This photo is the list of actions/changes/learnings one of my teams came up with in their most recent retrospective. This did not come from someone who went on training or read an article. It also didn’t come from a new Agile coach or Scrum Master. It came from them missing their sprint commitment and goal. This team only managed (on paper) to complete 8 out of 18 points; but they all knew they had delivered and learned a lot more than that measure reflected. Here are some things that they decided to do going forward:

1. If the team cannot reach consensus about the size of a story, then split it into two stories and size the smaller stories

One of the main reasons the team had such a poor burn-down is that they took in one quite large story which did not quite meet the INVEST requirements. For one, it was a ‘common component’ that was to be used in most of the later stories (so not independent). It also was not small enough – and turned out to be even bigger than the team had thought. During sizing, there had been some debate about its size and eventually reluctant consensus was to make it the smaller size. Turns out the less optimistic team members were right. This was one of the stories that was not done at the end of the sprint.

2. Keep Planning II – and use it to verify the sprint commitment

This is a team that often decides to skip Planning II (I don’t like it, but ultimately it is the team’s decision and so far we’ve muddled along without it). For this sprint, they decided that they did need a session to unpack the stories and how they would be implemented. Everyone agreed that without Planning II we would have been even worse off. They also realised that at the end of Planning II, there were already some red flags that the big story was bigger than everyone had thought and they could have flagged, at that point, that the commitment for the sprint was optimistic. The team agreed that, in future, if going into the detail during Planning II revealed some mistaken assumptions, then the team would review the sprint commitment with the Product Owner before kicking off the sprint.

3. Feel free to review story-splits in-sprint

Early in the sprint, the team were already aware that the big story was very big and probably could be split into smaller components. Their assumption was that this wasn’t possible once the sprint had started. For me, re-visiting a story split mid-sprint or once you start the work is not a bad thing: sometimes you don’t know everything up-front. It also, in the case where a story is bigger than expected, gives the Product Owner some more wiggle room (negotiation part of INVEST) to drop/keep parts of the story to successfully meet the sprint goal. Of course, where we have got things really wrong, then sometimes the sprint goal cannot be rescued and the sprint would be cancelled.

4. Raise issues as they happen

Pretty much summarises most of the above points. One of the agile principles is responding to change over following a plan, so when change happens make it visible and decide how to adjust the plan at that point. There’s no point in battling on as planned when you know that the planned path is doomed to fail.

I recently read the following article (which I am assuming was written within a Scrum context). Basically, it builds a case for a Product Owner to add more scope to an agreed sprint. It warns that this does frustrate the team and potentially impacts quality, however says it can still be done with the correct amount of justification. The basic agile principle that it bases this on is “Responding to Change over Following a Plan”.

This doesn’t sit well with me at all.

Messing with agreed stories once a sprint has started should be the exception and not the rule. It is very disruptive and de-motivating. Scrum uses time-boxes to limit work in progress and ensure team flow and sustainability (all lean concepts). Continuously changing sprint scope means it’s harder to complete stories to deliver working software. Scrum says that if you need to change the scope of the sprint, you should cancel the sprint. That means stop working, review the stories that are done, have a retro (after all, we need to understand how to improve so that we can avoid cancelling a sprint again), clear the task board, and plan and start a new sprint. It’s a significant event so the process around it should recognise that significance.

My preferred tool for managing change vs plan in sprint is a sprint goal. Agreeing an overarching sprint goal empowers the team to tweak sprint content (with Product Owner input) where it makes sense in terms of the overall goal for the sprint. If new stories arrive that are not aligned to the goal then either the Product Owner must wait for a new sprint to start oracknowledge that the sprint goal is no longer valid (and cancel the sprint). If your goals/requirements change often, consider shortening your sprint lengths. If they change so often that it is impossible to plan a week in advance, then perhaps a more Kanban-like approach will be better suited.

For me, changing stories mid-Sprint when you’re running Scrum points to a deeper issue, and merely substituting/adding stories addresses a symptom rather than dealing with the cause. There would be a number of ways to address that cause (sometimes it’s merely a case of educating the business or learning to say ‘not yet’). The important thing is to ensure everyone is aware that this is a big deal and help the team find the best way to deal with it in a way that ensures all agile principles are satisfied.

One of my three teams works mainly on a communications engine and provides a lot of operational support for new reports and static information, particularly around this time of the year. They’ve run Scrum without a Scrum Master for almost a year and have managed to keep things ticking over. After observing for one sprint (three weeks), I facilitated the following minor tweaks based on my observations:

Sprints now have an overarching sprint goal that the team can swarm around where necessary. I find a sprint goal is a simple and useful tool for helping teams maintain focus and make good decisions. We agree on the goal with the Product Owner during Sprint Planning I. I know some advocate that the goal be agreed before planning and possibly even as early as at the Sprint Review for the previous sprint, however in our world where we don’t really have a product, it’s easier to do it together with the sprint commitment. The goal conversation has also already helped us during Planning I where the Product Owner had to re-prioritise based on the fact that we couldn’t achieve all the goals with the team capacity available, so he had to make a call on which goal was the most important goal. Having a goal also led to some of our developers volunteering to support some testing work by creating tools to ease data comparisons. This reduced the manual effort required significantly, leading to us achieving far more in a sprint than we otherwise would have.

Defined our Definition of Done (DoD) which is now posted up on the board. For me the most useful part of doing this DoD was the exercise itself (see below) as it helped me better understand the release and testing cycles. For this team, most of the tasks are done at a story level and there was no work required at sprint boundaries to complete their DoD. The challenge across all teams within our IT department is that the first fully integrated testing environment is UAT, and this environment is only updated/available prior to major releases (which happen approx. every 9 weeks). This impediment is one which will need addressing over time and is on the Scrum Master forum’s radar.

Revived the practice of acceptance criteria for stories. The team opted to have these written on the back of their story cards. In this team, the most valuable aspect of having acceptance criteria is the conversation required to identify them.