Skip navigation
All Places > Alfresco Content Services (ECM) > Blog > Author: cthompson2

First published on Scrum Alliance Community Articles on 2nd Feb 2017.


During my 7+ years as a Scrum Master, I’ve worked with a number of different Product Owners. As I look back over them all, I notice how I considered most of them to be more than just colleagues. They became friends. How lucky I was to have been working with friends. But is this coincidence? On reflection, it strikes me what an important partnership the Scrum Master and Product Owner must form. The level that our relationship reached was merely indicative of the need to work so closely together with each other and the investment that we both made in this relationship.


The Scrum Master (SM) and Product Owner (PO) fulfill two key roles for the team. The SM nurtures the team and helps them to grow and become independent. The PO gives guidance to the team on the purpose and value of what they are doing. With this input from the two of them together, the team has the #support and guidance they need to apply their skills appropriately, produce positive results and to develop as individuals and as a group. I’ve seen the two roles aptly described as “leadership partners”. To this end, then, the SM and PO need a solid, supportive relationship and a united intent for the team. How do they achieve this?


Constant collaboration

The PO and SM must have open and honest interactions. They need to have regular conversations about their concerns for the team. They need a shared view on progress, process and the needs of the team. They need to be regularly available to each other, as much as to the other members of the team.


Shared goals

The PO shares the vision and strategy for the product whereas the SM promotes the vision and strategy for the team. Without both of these, the team will not be effective and therefore these “leadership partners” must share their respective visions and encourage each other in the support of the team achieving its goals.


Mutual respect

The PO and SM must understand, respect and value the unique contribution that each makes to the team. They must know the purpose and value of each other’s role and understand the unique way in which they deliver this. They must get to know each other and the strengths and weaknesses that each has. They should celebrate each other’s capabilities and show appreciation for each other on a regular and ongoing basis.


Mutual support

The PO and SM must support each other. They need to recognise when the other needs help or encouragement and they need to challenge each other to be even better and to grow in their respective roles. The Scrum Guide describes the “Scrum Master Service to the Product Owner”. Indeed, the SM supports the PO and supports the Team but nowhere does it describe who is supporting the SM! The SM needs support and encouragement too. The PO should reciprocate the support that the SM role offers to them so there is a triangular support network available across all the members of the team.


For two individuals working in such close and supportive collaboration it’s not surprising that this relationship can lead to a true and valuable partnership on which the team can rely and from which the team can truly benefit.


Can one size fit all?

Posted by cthompson2 Employee Dec 23, 2015

By Christine Thompson

A member of one of my Scrum teams recently pointed out that we only tend to use a limited range of numbers on our planning poker cards. Most of our stories get sized in the 3 / 5 / 8 range and he questioned why we weren’t using the full range of sizes for our stories. Here is my take on the situation.

Here is our sprint, that we need to populate with user stories:


Within the Scrum team in question, the stories being written for the work we need to complete are currently being pitched very well. They are small enough to be clear what needs doing but not so small that they’re too granular. Within the team, we’re starting to write stories that are generally of a similar size. This suggests that we’re breaking them down correctly, to a consistent and appropriate level. Our sprints look like this, populated with a number of uniformly sized stories:


The alternative would be to aim for stories within a not too narrow range – maybe 1 to 13 points. This allows you to populate a sprint with small, medium and large tasks. This is a good approach for the circumstances where you need to include a ‘large’ story, so the sprint must also contain ‘small’ stories too, to fill the gaps:


The one thing we want to avoid is populating a sprint with one, big story. Just bringing in one or two large stories carries a lot of risk, as in the last example below. If that story gets blocked, the whole sprint grinds to a halt:


So what are the benefits of sizing stories consistently? There was one occasion recently when we sized something at 13 points. The Lead Developer took it away and broke it down because it was considered too big to be properly understood. This shows that we’re trying for consistency and the sizing highlights when we have not achieved it. Anything above 8 points may be too large and complex to be sized accurately. Breaking it down ensures that the story is well understood at the appropriate level.

The important thing to note here is that we're not limiting our choice of story points to a fixed set but instead we're writing our user stories to a defined size.

Let me give you a couple of examples from another team. When a new PO joined the team, he was writing stories at a very granular level. The teams were giving them 0.5 or 1 point and asking him to combine them to make them bigger, as they felt too small to be worked on individually. Conversely, when he asked for a big, vague story about a database-driven feedback system, the team sized it at 100 points, showing it would need to be very well specified and broken down for us even to attempt to work on it. Here our use of the extreme planning poker cards showed a problem that needed addressing.

The exercise of sizing confirms we have pitched the story correctly and warns us when that is not the case so that action can be taken. It's unlikely that user stories are always going to be sized equally, and you would start to wonder whether the team were even thinking properly about them if they were. However, the correct preparation of stories for sizing, and the discussions to confirm our understanding of them, give us the best possible indicator that we understand the work we're doing and can successfully achieve the sprint.

Cross-skilling seems to be a hot topic amongst our Scrum Teams at the moment. But what does this actually mean and why should anyone want to do it?

What is cross-skilling?

Cross-skilling refers to the breadth and depth of skills that a person may have. We can consider three alternatives.

1. The Specialist has a great depth of skill within just one particular area.


2. The Jack of all Trades has a great breadth of skills, and can cover many areas, but none of them in much depth.


3. The Cross-skilled person has a specialism but is also able to cross into other areas where they have a limited level of skill but can help out. We would call this a 'T-shaped' person.


Why is 'T-shaped-ness' so good? Every team benefits from people who are experts at what they do. They are able to work quickly and effectively in their area of expertise. But what if these  specialists also understand something about each other's areas of expertise? They can now collaborate more easily with each other, help out wherever they can and generally extend the reach of the team. Let's have a closer look at some of the reasons for cross-skilling.

Why cross-skill?

What would drive an individual to become more 'T-shaped' and to extend their skills into other areas?

1. To fill a gap that the team doesn’t have


This makes the team more capable, by extending the skills it can cover.

2. To help out when the team need more of a skill than they currently have available


This makes the team more resilient because it can cope better with changes in workload and absences within the team.

3. To further the skills and experience of the individual


This is a bonus side-effect for the individual, in addition to the advantages for the team.

When to cross-skill?

The motivators for the individual to extend their skill set may be driven by:

  1. Opportunity: The project has a need, perhaps for a new skill
  2. Team-focus: The team has a need, perhaps for more of one skill
  3. Interest: The individual has a desire to learn something new

Cross-skilling should not be driven by Management but should be enabled and supported by them.

How to cross-skill?

Let's have a look at some example scenarios which should explain these ideas.

Case Study 1:

Jason is a Java developer who works on a team where test resource is stretched. He helps to write the automated tests for the project, as defined by the test specialist in the team. He’s not a test expert but he can use his Java skills to facilitate the automated testing.

Case Study 2:

Carla is a UI developer who has a desire to extend her skill-set. She’s working on a team with only one back-end developer, who is due to take extended leave later in the year. Having done some Java training at Uni, she takes a refresher course and begins to do some back-end work, under the watchful eye of the experienced Java developer in the team.

Case Study 3:

Sally is a Scrum Master working on a team that currently has no testers. She wants to help out in this area so she builds up her domain knowledge by completing the available online training and tutorials. Working alongside the team, she carries out some exploratory testing of the stories that are being developed during the sprint, raising any issues she finds with the Product Manager and Developers.

In summary, cross-skilling is a natural, organic process which occurs via an individual’s desire to expand their skills alongside their choice to support the needs of the team. Investing in a new skill may have a short-term cost but this is likely to be out-weighed by the long-term gain for the individual, for the team and for the organisation.

Several months ago we started looking at the Jira Version Report as a means to produce release burn-ups so that we could begin to forecast our deliveries using live Jira data. During the implementation of this chart, questions were raised about what data lies behind it and what events affect the way in which the chart is drawn. Many investigations later, and with great support from Atlassian, I can summarise everything that I have learnt about the Jira Version Report.

How the team velocity is calculated

The velocity of the team is fundamental to the forecast that the chart makes. This calculation counts the number of working days and the total of estimated story points to produce the average velocity per day. It considers the number of days based on the start date of the version, not of any Sprints.


Explaining the prediction strategy

The process would be as follows:

      • Count the number of days since this version has started and the current date (note: start of the version, not of any sprints)
      • Sum up all points completed until today
      • Divide the latter by the former and you will have an estimated velocity (points completed per day).
      • Simply keep adding up this number until you reach the total estimated points in the backlog.

If all weeks will have the same number of working days, it will be a linear prediction.

Setting the start date of the fix version

If the Fix Version in Jira has no start date set then the graph will begin from the date on which the fix version was first associated with an issue. If this is some time prior to beginning work on the version then the start date of the version should be set to the start date of the first sprint in which issues associated with that fix version were progressed.

Here's an example from one of my teams. We had a Fix Version which was created quite early on by the Product Owner as he planned a new set of features for the team to work on. It was some time before the team actually began progressing any of these stories in a sprint and the Version Report looked like this, with a predicted completion date of 27th Oct:


This chart was using the default start date of the date on which the fix version was first associated with a story. When I changed this to set the start date of the fix version to the date of the first sprint in which we progressed the stories for this version, the chart looked like this:


Our prediction date had been changed considerably, to 24th Aug. This is because the first chart had been including the velocity from February to April, even though the team were not progressing any of the stories. As a result, the prediction was much further out because Jira was including several weeks of zero velocity against the version. When the start date was correctly set at the start of the first sprint which included this version, then the prediction was adjusted correctly.

What makes the chart bend

Generally, the prediction line of the chart tends to be straight. However, under some circumstances, the line will bend on 'Today'. This can happen in either direction, inflecting upwards or downwards depending on the event which has caused it. The following are the events which I have found can cause the bend.

1. Non-working days

If there are more non-working days set on one side of “Today” than on the other, then the graph will bend accordingly as it would take a different number of days in the second half to achieve the same number of completed points from the first half.

For example, the graph will bend up slightly when there are more 'non-working days' in the first half, prior to “Today”, than in the second half.

2.  Closing and re-opening an issue

There is an open bug with Atlassian (GHS-11735) where, instead of subtracting the story points of a reopened issue, it keeps adding them up. Which then results in the incorrect prediction, where the velocity assumes that the team will speed up in the upcoming weeks and reach the goal more quickly. This means that closing and re-opening issues causes the line to bend upwards.

3. Removing the fix version from a closed issue

Removing the fix version from an issue which is already closed causes the line to bend upwards. (This does not happen with issues that are open, only with those which are already closed when the change is made.)

It's worth being very cautious about these events, as the bend in the chart is often not reversible. Here's an example from one of my teams, which resulted from removing the fix version from a number of closed stories:


How are scope changes handled?

Changes to scope other than those described above seem to be handled in a consistent and expected way. This includes the following:

    • Increasing / reducing the story points on an issue


    • Adding an issue to the fix version or removing the fix version from an open issue

When such a change is made, this alters the target scope on the right-hand side of the graph so that the prediction line intersects at an earlier or later point, thus giving an updated forecast date. See the following example, where the scope was reduced, giving an earlier forecast for completion:


Estimating the full scope of the project

The Version Report will forecast for the issues that have been estimated and, whist some of the work remains un-sized, the graph will not reach 100% (see above screenshot for an example). There is an open bug with Atlassian for this issue (GHS-12137), as the graph keeps increasing the range of story points when more story points are committed. In this way, the percentage of progress on the project can never reach 100%, as it will always set a higher range of story points, more than the team has committed in the stories.

In conclusion

I have found the Version Report to be a very useful tool in the prediction of the work that my teams are progressing. However, for the report to be widely adopted in our organisation, I think it's essential that we can understand how it is constructed so that we can trust its output. With very little documentation available online about this chart, I hope that the details that I have collated here can shed a little more light. Happy forecasting!

The Jira burn-down chart tracks the total work remaining in the sprint and projects the likelihood of achieving the sprint goal. By tracking the remaining work throughout the iteration, a team can manage its progress and respond accordingly. Having spent some time getting to grips with the intricacies of the burn-down chart, I thought that I would share my understanding. 

The green line is the burn-up line which indicates the time spent ie. the sum of all the hours logged against the tasks in the sprint. The red line is the burn-down which indicates the time remaining ie. the total estimated time in the sprint minus all the hours that have been logged. You may well expect that as the sprint progresses, the time burnt-down on the red line will equal the time burnt up on the green line but it seems that this is often not the case. 

Here’s a snippet from a recent burn-down chart for one of my teams, mid-sprint:


You can see that the time indicated on the axis for the burn-down is 84 hours but the time indicated on the axis for the burn-up is 60 hours. So we have logged less time than we estimated we would need. For example:


If this consistently happens, it tells us something about us overestimating the time we need on our tasks. However, perhaps of more concern would be the converse of this. For example:


Here, we have burnt-up more work than we burnt-down. This is because you can log more hours than you have estimated, for example:


However, you cannot have a negative time remaining. If you log more than you estimated, the remaining stays at zero. This means that the total represented by the time spent (green) line can exceed the total represented by the time remaining (red) line and indicates that work is taking longer than we estimated. 

What happens if we increase our estimate because we find out, part way through, that a task will take longer than originally thought? This is where we see the upward spikes in the time remaining (red) line, as indicated above. The start point of the ideal work (grey) line and the start point of the burn-down line do not adjust on the axis to reflect that the additional work has been added, so this exacerbates the difference between the apparent burn-down progress and the amount of work completed on the burn-up.  

If your estimates were exactly correct, then adding the time for the scope increases to the apparent burn-down value should then equal the amount of work logged in the burn-up. This isn’t the case in the example above (ie. 35h + 20h + 4h still does not equal 70h) because we are also suffering from under-estimating the time that the tasks will take. 

Given this understanding of what the lines on the graph reflect, it appears that there is useful information to be had here about the accuracy of estimating, especially where we are taking longer on tasks than expected, which may need some further investigation. However, I would only be concerned if this were a regular trend and was matched by a similar discrepancy in the story points estimated and completed within the sprint.  

One final thought is that we do, of course, want the burn-down to reflect reality and not just match the ideal progress line. So being honest about the progress of the work in a sprint is far more important and useful to the team than artificially logging work to achieve a perfect burn down.

by Christine Thompson

Self-directed, cross-functional teams

Here’s one of the things that I love about Scrum. Scrum is a simple system which allows people to be intelligent within it. It assumes that team members do the best they can within the constraints of the system they work within. If something goes wrong, it is generally assumed that it is the process that is at fault and not the people. The Carrot & Stick approach doesn’t motivate people in skilled work.  Instead, autonomy, mastery and purpose do.

Scrum teams should be self-managed, self-organized and cross-functional. Team members take their direction from the work to be done and not from the Scrum Master or stakeholders. To empower the team, they need authority, resources and information. Scrum itself values team success over individual performance.

Each scrum team should be made up of team members with cross-functional, “T-shaped” skills. Whilst people may have an area of speciality, they also have a set of broader skills which overlap with those of their team-mates. If a skill-set is over-stretched, then other people need to step in and fill it. If a skill-set is missing, then we need to train people up.

Finally, reforming teams frequently is wasteful as it takes a long time to establish a performant team.

Powerless teams

So what are the characteristics of a powerless team? They may be heavily directed by the Scrum Master and/or influenced by people outside of the team. They’re not making their own decisions, they’re being told what to do. Perhaps they get no value from the daily stand-up: they address the Scrum Master and use it as a status update. Individuals either don’t participate or they argue about everything. People work in isolation and just “do their own thing”. Communication happens indirectly, via comments in tools instead of face-to-face.

Empowered teams

So what does an empowered team look like? The team share an understanding of their tasks and what it takes to complete them and they find their own answers without having to revert to other authorities. Individuals offer to help each other out whenever and wherever they can. The team values its interactions and conversations; all the meetings they hold are considered of value. Everyone shows respect to everyone else, everyone in the team is valued equally and the whole team works towards completing their goals together.

Role of the Scrum Master

So what’s the role of the Scrum Master in empowering the team? The Scrum Master is not the same as a Team Leader or Tech Lead. They are a “Servant leader” – they facilitate but do not manage the team. They may question and challenge things but they have no authority because the team manages themselves. It’s important that the Scrum Master sets the tone of the team in their own behaviours and they also provide the social grease on the distributed team, encouraging teams to use the thickest form of communication available at any time.

For example, the Scrum Master disempowers the team when they:

  • Assign or ear-mark tasks for individuals - team members should decide what they will progress next themselves, based on the information they are given in the scrum meetings and from their understanding of the sprint backlog

  • Influence the sizing of tasks - unless they are performing a dual role as an engineer on the team, the Scrum Master does not take part in, or steer the outcome from, the sizing discussions

  • Make design / implementation decisions for the team - again, unless they are also an engineer on the team, the team members themselves should be making decisions about how a task will be implemented

  • Interfere with the flow of the sprint - if the the team has all the information it needs about the priorities and tasks in the sprint, then there is no need for the Scrum Master to influence people on what tasks they should be working on and when

  • Chase progress instead of chasing blockers - the Scrum Master is there to facilitate and not to manage the team. Asking for progress updates does not engender trust between themself and the team. Such information should be available from the task board and the Scrum Master should only be chasing impediments.

Instead, some examples of what the Scrum Master might do to empower the team:

  • Reduce / eliminate “command and control' practices so that teams can run their own sessions openly and honestly; ensure that dysfunctional meeting participants are controlled

  • Ensure that barriers between team members are removed

  • Work with the team to remove impediments effectively

  • Protect the team from stressful outside influences and unnecessary interruptions

  • Prove a level of true commitment to the team - teams will not feel truly empowered until they see that the Scrum Master is serious about the role

Final thought

The ultimate goal of the Scrum Master is to coach and support the team to the point at which is becomes truly self-organising, autonomous and empowered. In the words of Nanny McPhee: “There is something you should understand about the way I work. When you need me but do not want me, then I must stay. When you want me but no longer need me, then I have to go. It’s rather sad, really, but there it is.”


Posted by cthompson2 Employee Mar 18, 2015
by Christine Thompson

Why ScrumBan?

I first started looking into ScrumBan when I was working with a team who had been doing a prolonged period of feature development and had a well-established Scrum process. Everything was working well for us until we started to transition into a phase of bug fixing and support. Suddenly we found that we had too much support to have predictable sprints. We could never finish a sprint because the support tasks couldn’t be sized accurately. Our priorities were constantly changing, as new issues came in, and we couldn’t lock-down the sprint. Things went into and out of the sprint and our burn-down started to look like an electrocardiogram.

I started to question then whether we should be looking at a continuous workflow and moving over to Kanban. This way we would be able to respond quickly to priority changes, limit our work in progress and work on tasks that would take more than sprint. But Scrum had worked so well for us that I was reluctant to move away from it completely. This is when I hit on ScrumBan.

What is ScrumBan?

ScrumBan combines the framework of Scrum with the principles of Kanban. It is more prescriptive than Kanban, which has no roles or meetings, but is more responsive to change than Scrum, where change can only be accommodated at the sprint boundary. ScrumBan retains all the roles and meetings of Scrum but uses the Kanban continuous workflow board. The daily stand-up focusses on flow of tasks across the board and reviews what it would take to move each one forward. The workflow can even include both support and feature work items on the same board, for teams who have to progress tasks in both areas at once. This is a neat solution to dividing teams in half, where those who end up in the support team are generally less impressed than those who remain on the feature team! It allows people to vary the type of task they pick up each time and to share the support load.

Using the Kanban board allowed us to take advantage of some of the lean principles of limiting work in progress and eliminating blockers. We had a limited number of “Ready” slots available on the board, which the product owner would fill with the top priority items. Should priorities change, or new requests come in, these could be swapped in and swapped out as needed. Ready to progress items were ordered in priority and the team was asked to try to progress the top items first, wherever possible. This was a real exercise in team empowerment and collaboration, and people worked hard to pick up priority items first, rather than those which just looked the nicest! As the Scrum Master, my role remained to facilitate this process and assist to eliminate the blockers that arose.

ScrumBan activities

We kept many of the Scrum ceremonies in place, relatively unchanged. The daily stand-up reviewed the progress on the board and allowed individuals to exchange information and offer assistance, even though they weren’t interdependent from working on shared user stories. The stand-up also allowed the opportunity to review our work-in-progress so ensure that individuals weren’t progressing too many tasks in parallel and that nothing was blocked. We retained a weekly backlog sizing meeting to review the new tasks in the backlog. The sizing exercise was still of value in allowing conversations to be held and shared understanding to be reached on what the tasks entailed, even though we weren’t tracking our velocity as before. The Product Owner maintained a backlog of around 10 items in the to-do list at any time, pulling in more from the backlog as soon as the list ran low. As new, high priority items came in, the Product Owner would add these to the top of the to-do list, removing lower priority items back onto the backlog, as necessary. The Product Owner was also always on hand to answer questions about the requirements around the issues that were being addressed and the test coverage necessary to extend our regression suite.  In our case, we didn’t hold a sprint review-type meeting, because the increments were limited to bug fixes. However, I see no reason why there shouldn’t be value in this type of meeting, for sharing the solutions that had been implemented. And, of course, retrospectives were as valuable as ever in reviewing our process and making improvements as the team felt necessary.

Final thoughts

The advantage of moving from Scrum to Scrumban, rather than pure Kanban, is the retention of much of the Scrum framework. For a team that needs to move from feature work, to support & bug fixing and back again, this provides a less onerous transition as many of the meetings and the general heartbeat of the team remain unchanged. Further, even for teams who only ever do support, I still see a great deal of value in having the Scrum roles and ceremonies in place as I believe that these add a lot of value which could be missed in a pure Kanban environment.
by Christine Thompson

One of the biggest bones of contention that I seem to have had with my various Scrum teams is around sizing and estimating. There seems to be a level of confusion about why to size, how to size, what units to use etc. etc. Whilst there are guidelines out there (for example, see “Agile Estimating and Planning” by Mike Cohn) there is, of course, no right and wrong way to do this and teams must settle on the solution that works for them. But let’s at least review what those guidelines are, as a starting point.

Sizing User Stories

User Stories are generally estimated at a high-level, in story points. They are sized relative to each other, rather than in absolute terms. The size of the story, in story points, is a function of its complexity to implement, the effort involved and any risk associated with it. One neat example, given by an old colleague of mine, was for a user story which required the operator to hit the X key once, on the keyboard. Of course this would be low complexity and low effort but if the story increased to hitting the X key one million times, then the complexity is still the same (it’s still a simple task) but now the effort involved in significantly increased and therefore the size of the story is increased too. So both of these factors influence the relative sizing of the story, along with any risks or unknowns that it contains.

Why size the story?

I would suggest two reasons for this. The purpose of the estimate is to track velocity so that we can predict when features will be completed. If we know how many story points we can complete in a sprint, and we know how many story points remain on the backlog, we can forecast when features can be delivered. Another key purpose for sizing has to be around the conversation that this draws out of the team. For the individuals to agree on a size, they have to reach a shared understanding of what’s required in the story and they have to be able to agree the size they assign. The discussion it takes to get the individuals to reach consensus is of great value in ensuring a thorough and agreed understanding of the work. Even if we threw the estimate away at the end of the sizing there would still have been value in the exercise.

Sizing Tasks

Once we have a user story of the right size (generally 8-13 points, depending on your own ‘value’ of a story point), we will often break this down into individual tasks. This allows the team to understand the individual pieces of work that will be performed to implement the story and to be able to parallelise the work with two or more people. So what about the sizing of these tasks? Tasks are generally sized in ideal time. They are low-level and small enough to know roughly how long we will spend on them. The purpose of sizing the tasks is to allow us to burn-down work during the sprint, so that we can follow our progress and identify early if we are not on track.

So if we add up the time taken for the tasks, we can calculate how long it takes to implement a story point, right?

Wrong! Velocity is an average over time and takes a number of sprints to establish. Some stories of the same story point size will take longer to complete than others of the same size. Velocity takes into account a whole team over a period of time. Tasks relate to one person doing a small amount of work. You can’t equate the two and they serve a separate purpose.

So, in summary:

Stories are sized in Story Points which provide a high-level comparison of complexity and are externally visible to the stakeholders.

Tasks are sized in ideal time which provides a low-level measure of effort and are internally visible to the team, allowing them to track progress within a sprint.

I’ve worked with teams who cannot cope with the abstract concept of story points and need to work in the real world units of time. They estimate everything in either elapsed or in ideal time. They admit that, if forced to use story points, they will have a conversion factor in their head which will allow them to supply this. These are the teams who may benefit from a better understanding of the concept and abstraction of story points. I’ve also worked with teams who prefer to do everything in story points because they hate the idea of switching between the abstract complexities and the actual time taken. They feel that it makes them equate story points to time, which they want to avoid. This seems a slightly more understandable approach, although not always well supported in Agile project tracking software.

The final word on this, of course, has to belong to the individual team and they must do what works best for them in order to achieve their needs in terms of planning and tracking their work. If it works for them, then it isn’t broken.

Filter Blog

By date: By tag: