blog

My first Scrum team in the wild

Published on
7 minute read

My first Scrum team in the wild   Over the last year I have invested a lot in Scrum. A few months ago I was assigned to teach a two day Scrum course for which I had to build and deliver the material. The team that received the beta of the course has now just finished their first sprint!


Although I was unable to be the teams Scrum Coach (paperwork relating to citizenship issues) one of my very experienced colleagues (Rennie Araucto) took up the challenge. This was Rennie’s first foray into serious Scrum and he attended the same training course; well I honestly could not have asked for a better person to take this team through its first sprint.

My first Scrum team in the wild  

Figure: Pretty much the best sprint 1 burn down I have ever seen

This is probably the very best Sprint 1 burndown I have ever seen. Usually a team will over commit on at least the first, second and third sprints as well as having a tendency to remain oblivious to the opportunities they have in the Scrum process to correct their mistakes. This is usually through no fault of the individuals, but of a IT industry that has consistently taught and rewarded people for anti-patterns to delivering better software.

The data show above is the difference that can be achieve by both having a Scrum Coach and listening to their advice. Most teams fall down on the latter even when the former is satisfied, but I can only applaud the openness of The Scrum Team and their management in adopting both the action and the theory of Scrum in addition to the verbiage. I am sure once they are passed their 10th sprint there will be many changes that they want to make to the process they will have achieved, but sticking to their guns at this stage will serve them well. The trap that they could still fall into is complacency on having such a good sprint. I do worry that their second sprint could be a disaster if they fall back on unhealthy anti-patterns.

Here are a few of the questions that came up during the course of the sprint:

When are Story Points added and updated?

When used correctly Story Points are a fantastic way of doing estimation. Once you accept that we humans generally suck at estimating things far in the future as well as things we will not be doing ourselves things can get a lot better.

If we take estimation as a team effort and make sure that there is consensus within a team for how complicated something is in relation to the previous complexity estimates we should at least know which stories are more complicated to implement than the previous one. I always urge teams to reach an agreement as a whole, but not to the point of arguing over wither something is a 8 or and 8.5 (or even a 2 or a 3). When it gets to that level I always recommend an average and move on.

Back to the question, I believe that Story Points are ONLY added or changed at the Sprint Planning meeting. Rough order of events:

In reality the pruning of the Product Backlog by the Product Owner happens all the time and anyone is able to add new User Stories to the end of the Product Backlog at any time.

We will end up eventually breaking things down into hours, so why bother doing story points at all?

This is a really common questions and is pretty easy to explain. First lets assume again that we are totally crap at estimating. If that is the case, we want to spend a minimal amount of time estimating things that we will do in the future, or even not end up doing at all. When we do a complexity estimate we let the Product Owner know that we think that things are only so big. This gives them a chance to reprioritise the things that they thought were quick wins, but which are hard, and visa-a-versa.

Now, in  Sprint Planning (Part 2) we can concentrate on only doing the hard work of breaking the top story down into fine grained tasks without the need to worry that we are doing this unnecessarily. Yes, at the start we will have say two User Stories at 12 points that end up being 80 hours and 120 hours respectively, but once you get around to your next Sprint Planning (Part 1) session you will have a better idea of how much complexity you have in your application. This knowledge can only increase over time.

When should the team activate a User Story?  At the beginning of the sprint or when they start working on it?

I love easy ones: When you start working on it.

In order to understand the relationship between the amount of work that you committed to and the amount of work that you got done it can be handy to see exactly what you did not even have time to start.

What do you do with stories that are not finished in a single sprint?

There is a lot of debate on this one. If you are using physical cards then that physical card just goes onto the backlog and all of the outstanding tasks go into the bin. I like to follow that with my data as well. Just move the incomplete User Stories back to the Backlog and Close it indicating that is was not done (Using the Visual Studio Scrum template you mark it as Removed with a reason of Removed from the backlog.

My first Scrum team in the wild  

Figure: Agile 5.0 Task removed from the sprint backlog

My first Scrum team in the wild  

Figure: Visual Studio Scrum 1.0 Task removed from sprint backlog

The User Story may then be added to the next Sprint if it is prioritised by the Product Owner. It would be up to the team to pitch its completeness or otherwise to the Product Owner in order to prioritise it.

Rule: Never leave uncompleted work in a sprint. Its untidy and causes confusion

Conclusion

This team has made some fantastic efforts for their first sprint, but should not get complacent. I am very impressed of the work that Rennie has put in and I really enjoyed our long Scrum conversations My first Scrum team in the wild

people-and-process blog agile develop nwcadence people practices process scrum

Connect with Martin Hinshelwood

If you've made it this far, it's worth connecting with our principal consultant and coach, Martin Hinshelwood, for a 30-minute 'ask me anything' call.

Our Happy Clients​

We partner with businesses across diverse industries, including finance, insurance, healthcare, pharmaceuticals, technology, engineering, transportation, hospitality, entertainment, legal, government, and military sectors.​

Akaditi Logo
Boxit Document Solutions Logo
Xceptor - Process and Data Automation Logo
Kongsberg Maritime Logo
Qualco Logo

CR2

Brandes Investment Partners L.P. Logo
Alignment Healthcare Logo
Cognizant Microsoft Business Group (MBG) Logo
Flowmaster (a Mentor Graphics Company) Logo
Sage Logo
Trayport Logo
Epic Games Logo

NIT A/S

Slaughter and May Logo
Jack Links Logo
Lean SA Logo
ALS Life Sciences Logo
Washington Department of Enterprise Services Logo
New Hampshire Supreme Court Logo
Nottingham County Council Logo
Ghana Police Service Logo
Washington Department of Transport Logo
Department of Work and Pensions (UK) Logo
ProgramUtvikling Logo

CR2

Xceptor - Process and Data Automation Logo
Trayport Logo
Teleplan Logo
Big Data for Humans Logo