One of the most common questions I hear from Business Analysts (BAs) at our Certified Scrum Master (CSM) and Certified Scrum Product Owner (CSPO) classes is:

"How does my role as a BA change on an Agile project?"

Or

"What do I document as a BA on a Scrum team? And how much?"

There’s certainly a lot of frustration out there because it’s not clear-cut, leaving BA’s confused and unsure of what they should be doing. So let’s look at some answers to these questions.

What we used to do…

So on a traditional Waterfall project it was straight forward. A BA’s role involves gathering requirements at the beginning of a project, producing relevant documentation which is then shared with downstream teams who will formulate a design, implement the solution, and eventually test the end result. In some cases, BA’s are also involved at the tail end of the project during User Acceptance Testing (UAT).

Now while this all makes logical sense, and does work at times, there are a number of challenges that may occur.

The ‘requirement’ challenges we’re trying to solve with Agile

Miscommunication

I like this quote by George Dinwiddie:

Remember, it’s not the documentation that needs to be in sync, but the people.

While documenting all our requirements upfront can give us a greater sense of control and certainty, there is a risk that the documentation (or at least parts of it) will be misinterpreted. What if our architects, programmers and/or testers misunderstand what has been written?

Misinterpretations lead to incorrect assumptions, incorrect assumptions lead to mis-aligned expectations, and mis-aligned expectations lead to unhappy customers 🙁

It can be incredibly frustrating when we’ve painstakingly documented the requirements, only to have them misinterpreted (or worse, skimmed over or ignored!) at later stages, and what has been produced at the end of our waterfall sequence is not what was expected!

Unknowns

As a BA it can feel like you’re expected to be an oracle, seeing into the future and coming up with the perfect solution upfront.

Now while we can spend a great deal of time understanding the problem to be solved and potentially coming up with what appears to be the most appropriate solution, there are many variables not in our control that will impact what has been decided upon, such as:

• Changes to government legislation
• New technologies
• Leadership changes
• Competitors
• Newer, better ideas

When these variables change in the future, it means our perfect solution is not-so-perfect anymore and we need to amend our requirements.

At later stages of a waterfall this can become painful, difficult and expensive. Now as humans, what do we do when something is painful, difficult and expensive? We don’t do it! In turn we deliver a solution that isn’t ideal.

Lead time

The requirements gathering phase naturally takes time. There can even be hesitation when signing off on requirements. Why is that? Well if we only have one shot to get these requirements right, we’re going to make damn sure we get them right 🙂

In turn, there is a long lead time before our customers receive the solution and confirm that it meets their needs. The longer it is before they confirm their needs have been met, the greater the risk that the optimal solution will have changed.

What’s different about ‘requirements’ on an Agile project?

So Agile, by no means a silver bullet, is attempting to help us avoid these potential traps. How does it do this, and how does the requirements elicitation process change?

Firstly, rather than running our phases in a sequence, you could liken them to running in parallel with one another:

So that means BA’s aren’t involved only at the beginning of an Agile project, but constantly throughout. This reduces our lead time, and we start delivering value to our customers earlier.

Where does the Business Analyst get involved then?

Most organisations now adopt the Agile framework ‘Scrum’. At the heart of Scrum, we have a cross-functional team. This team potentially includes programmers, testers and yes, you guessed it, Business Analysts 🙂

So what’s the big idea? Rather than having functional teams working independently of one another, we have small cross-functional teams where individuals from different functional groups work together. This eliminates barriers between individuals and minimises hand-offs improving the way the team communicates.

What does a Business Analyst do on a Scrum delivery team?

Your job as a BA is to ensure the team understands the needs of the customer, and delivers the highest business value possible, in the shortest amount of time. This effectively means you’re providing the team with a steady stream of requirements.

To do this, instead of defining all the requirements upfront for the entire project, the requirements will be broken down into smaller deliverables, and the focus will be on the requirements that are most important at that point in time. This is what we call "Rolling wave analysis".

What does a Business Analyst document on an Agile Project?

This is where it gets tricky, especially when the Agile Manifesto promotes the value “Working software over comprehensive documentation” which has led to the widespread misconception that Agile teams do not document, which is not true. So what do you document then?

To help, think of the common Agile saying:

Focus on outcomes over outputs

You will already be doing this as a BA, where you’re thinking about the needs (outcome) of a customer first over the solution (output) that we will give them.

So if we were to apply this to the role of BA, we might say:

Focus on the delivery of value (outcome) over documentation (output)

As an Agile BA, you need to ensure the team is delivering the highest value possible in the shortest amount of time, instead of focusing on documentation. So how can we ensure our team is delivering the highest value possible in the shortest amount of time? Does it require comprehensive documentation? Sometimes but not always.

Agile Requirement Techniques

On an Agile project we want to be able to help our team understand the needs of our customers as rapidly as possible, so they can get started on implementing the solution. Comprehensive documentation may not be the optimal delivery method for our requirements.

So instead of comprehensive documentation, an Agile BA will leverage other techniques, such as:

• Lightweight documentation (User Stories, Job Stories, Use cases etc)
• Facilitate structured workshops to enable high-fidelity communication via face-to-face discussions
• Behaviour Driven Development (BDD) where our automated test suite becomes what is called ‘Living Documentation’, and automatically evolves as our application changes
• Carefully splitting requirements into increments that can be delivered iteratively, and prioritised by business value

Would you like to learn more about the Agile BA techniques mentioned above? Join us at an upcoming Virtual Agile Business Analyst course

In summary

• An Agile BA now performs rolling-wave analysis through-out a project, rather than all upfront at the beginning
• Agile BA’s form part of the Scrum cross-functional delivery team
• The Agile BA is responsible for helping their team understand the needs of the customer, and deliver the highest business value in the shortest amount of time
• Agile BA’s become experts in delivering requirements rapidly by leveraging light-weight documentation, facilitating structured workshops, utlising techniques like BDD, and breaking down requirements so they can be prioritised

What next?

Checkout this worksheet. Print it out and fill in answers to the questions to help you improve your approach to Business Analysis on an Agile team.

Would you like to learn more about the Agile BA techniques mentioned above? Join us at an upcoming Virtual Agile BA course .

This blog explores the power of the Agile Team and how HR can adopt this approach in their Agile journey. As with my previous blog What is Agile HR? I will be using Scrum as the Agile framework.

Here are some of the unique characteristics of an Agile team:

• The size of the team is determined by the two-pizza rule – Jeff Bezos’s two-pizza rule can be used to guide team size, making their meetings highly interactive without unnecessary communication overhead. With this rule in mind, Agile teams can be made up of more than 3 people, but less than 9 people.
• The roles talk to responsibility, not seniority – Unlike traditional teams, where one’s role gives us an indication of their hierarchical position within the team (for example, HR Coordinator, HR Manager, HR Director etc.), roles within an Agile team are there to describe what the role is responsible for, not where they sit in terms of seniority. Every Scrum team has 2 key individual roles:
  • The Scrum Master – this role is focused on the people, the process, and how they can best work together. Scrum Masters are there to help the team learn and apply Scrum and to remove any obstacles or impediments which get in the team’s way.
  • The Product Owner – owns the vision/product/initiative that the team is working to achieve. They are focused on maximising the value and do this by translating the vision to the team, setting the direction, compiling, prioritising and refining what needs to be achieved.
• The team is cross-functional and multi-disciplinary to fit the purpose – Now this doesn’t necessarily mean you need someone from every function across the business to make up the team. What it does mean, is that the team has all the necessary knowledge and expertise to deliver that particular vision/initiative – that they are multi-disciplinary. Whilst they each bring their unique skills and experience, when they do come together as a team, there are no fixed specialist titles and no hierarchical ranks. Each member is there to work together to contribute to the achievement of the vision/initiative in whichever way they can.
• The team is self-organising because they are the ones who know best – They know what they need to achieve, they have the right skills and expertise to do it and they have Scrum’s artefacts and processes to guide them. With this, teams self-organise – meaning they decide how much work can be achieved in each Sprint and how to best complete the work. This is up to the team to decide, not the Scrum Master or Product Owner!

So, what does this mean for HR. How can we adopt and apply these characteristics to help set up an Agile team to deliver our next HR initiative? Here are my top 5 tips to help you:

1. Pick your team members carefully to suit the vision/initiative – Your team needs to have the right skills, experience and capacity to achieve the goal/vision. For example, if your vision is to design a new onboarding program, then your team may need members from the following areas:
   • HR COE (Centres of Excellence)
   • Talent Acquisition
   • HR Services
   • IT (every new team needs their technology!)
2. Cross-functional won’t always mean outside of HR – Inviting people from other functions across the business to help use, design and deliver value-add initiatives won’t always be possible due to capacity constraints or beneficial (depending on what you are trying to achieve). So, don’t assume cross-functional will always mean outside of HR. Consider cross-functionality with the subtle silos that can sometimes exist within our very own HR operating model. For example, business partnering / HR generalists versus centre of excellence / specialist roles. This not only invites in different skills and experiences, but also provides an opportunity for growth and development whilst strengthening relationships across the broader HR function.
3. Stakeholders can help co-design without being part of the Agile team – We need to remember to invite stakeholders in to help co-design the initiative/product. Through Sprint Reviews, stakeholders will have the opportunity to provide feedback and give input to help maximise the value of the initiative/product. So with that, pick your stakeholders carefully, just as you would pick your team. For example, if your team is implementing a new HRIS system, your stakeholders should extend to a variety of end users – from a manager who needs to approve leave, through to individual contributors who need to update their personal details. Don’t just assume that your stakeholders are the ones who are funding the system.
4. Consider renaming the key roles to reflect your vision and organisational culture – The 2 key individual roles of Scrum Master and Product Owner are titles which may confuse your team or not align to your organisational culture. Many teams have looked to alternative titles which speak the language of their organisation whilst staying true to their core responsibilities. For example:
   • Scrum Master – Agile Team Coach, Agile Lead, Process Owner
   • Product Owner – Initiative Owner, Outcome Owner
5. Educate, Inspect and Adapt – your Scrum artefacts and activities continuously. Because a lot of this will be new to the team, you need to make sure you spend time educating them on the Scrum artefacts and activities (e.g. Product Backlog, Sprint Backlog, Sprint Reviews, Retrospectives etc) and then inspect and adapt these to drive continuous improvements and further increase their value and the performance and productivity within the team.

I hope these 5 tips challenge you to think differently about the set up of your Agile HR Team. If you and your team are keen to find out more about Agile ways of working for HR please reach out to us at support@axisagile.com.au .

Stay tuned for my next blog which will look to explain each of the Scrum activities and how they are used to drive team engagement, productivity and alignment.

I’m sure a day doesn’t go by in any business without the word ‘Agile’ being thrown around. Every organisation is looking for ways to be more Agile in order to survive in today’s VUCA environment. And with this, HR professionals are being challenged to facilitate and support this change, calling for them to go Agile HR. But what does it mean to be Agile and what is Agile HR?

Unfortunately, the term Agile is being misrepresented and misused in businesses today. This is causing a whole lot of confusion and misunderstanding for many HR professionals as well as the businesses they support.

Organisations are labelling the tough decisions they are forced to make as ‘Agile’ in order to put a positive spin on unpopular decisions. So, let’s clear things up…Agile is not about removing necessary layers within a structure, nor is it about eliminating the role of the manager, and it is not about moving to activity-based working.

Agile is a mindset! It’s an attitude towards how things get done. These attitudes are best summed up within the Agile Manifesto (see below) which declares that as Agilists, we value:

Now this doesn’t mean that we completely disregard what is on the right. It just means that we value the items on the left more. And whilst this may sound simple, it is easier said than done. A change in mindset for individuals, teams and organisations means unlearning old habits and ways of working which are deeply embedded – something we know as HR professionals isn’t an easy task.

So how do we live by these new attitudes? What does it mean to go Agile?…. There are a number of different Agile frameworks (such as Scrum, Kanban and XP Programming) which have been designed and built to support these Agile values. Scrum is the most highly used framework across Agile teams and whilst it originated in the early 1990’s to improve software development, it is very quickly growing into other functions such as HR, marketing, finance – each looking to realise the benefits Scrum brings to both the team and the product/project they are delivering.

Scrum is essentially a way of working. It is a framework in which cross-functional teams develop products/projects in an iterative and incremental manner. Scrum allows these teams to focus on delivering the highest business value in the shortest time. It is not a set processes, techniques or a definitive method, but rather a collection of techniques and processes that are designed to enable a team to work smarter, be happier and collaborate more effectively, all whilst continuously improving the product and ways of working through regular and ongoing feedback loops.

When we apply this to HR and consider what Agile HR is all about. It is important to note that the true definition of Agile HR is two-fold:

1. Firstly, it is about HR adopting Agile principles within how they operate and deliver as a HR function. This sees HR operating in Scrum teams with set roles, activities and artefacts to deliver their HR strategy.
2. Secondly, it is about HR re-thinking and innovating their people processes to better suit an Agile organisation.

To sum this up as beliefs and attitudes, the Agile Manifesto has been adapted to describe what Agile HR values (see below). And just like the Agile Manifesto, whilst there is value on the right, it is all about valuing the items on the left more.

But before HR go about innovating their people processes and labelling these changes as ‘Going Agile’, HR must first learn, adopt and experience Agile principles in the way they go about their work as a function. It is important that HR themselves shift their mindset and experience this new way of working first hand before they go about changing how they support an Agile organisation. Its starts in our own backyards first!

As an HR professional with over 15 years experience across both generalist and specialist roles, I see the value Agile brings to addressing some of the challenges we face as a HR function. I am eager to share this with HR so that they too can realise the benefits Agile brings to all teams, not just software teams. To do this, I have collaborated with AxisAgile to bring Agile to HR and helping HR teams transform the way they work.

To find out more about our Agile HR training and coaching, please contact us at support@axisagile.com.au!

Without further ado, let’s debunk the final myth. This one is particularly nasty because it leads to some pretty serious Agile religious wars (and we all know how religious wars end...). This is the myth that unless you are able to leave a training course and immediately work in cross-functional teams that are able to develop nice working increments every Sprint while keeping their products in a constant state of readiness then you can’t do Scrum or you have to practice the much maligned Scrum-But.

For example, I overheard a comment at a recent training course that went something along the lines of, "That XYZ team are doing pretty well BUT they have to conduct a testing Sprint every 3 or 4 Sprints to catch up with their regression tests and as such they’re not doing real Scrum."

Guess what? When you start using Scrum things are not going to be perfect. Your team is not necessarily going to have the test automation maturity to be able to maintain a product in a continuous state of readiness. That is ok. By my reckoning, there is a big difference between Scrum-But and what I call Scrum-In-Motion.

For example, I reserve Scrum-But for teams that say they’re doing Scrum but don’t bother with retrospectives. Or they say, "Hey we do Scrum but we have closed Reviews just for the team". In fact labeling those teams as doing even Scrum-But is generous IMHO.

That being said though, Scrum would be pretty hypocritical if it expected every team to be able to get things up and running perfectly at the beginning. Scrum is about incrementally and iteratively improving not just our products but also the process of Scrum. In the earlier example about the team getting up and running with automation tools, I say that so long as the team is doing it’s very best to continuously improve its current test automation processes, while at the same time sticking to the core Scrum rules, roles activities and artifacts as articulated within the Scrum Guide then they are certainly still doing Scrum. They are just finding their feet, but with desire and focus, this team will get better and better and that is what Scrum-In-Motion is really about.

It is important that after 21 years (yep, Scrum just celebrated it’s 21st birthday) we reflect back on the actual intent of Scrum. The desire to close feedback loops and continuously improve at both a product AND process level is what it’s really all about. That is the heart of Scrum.

So thank you for hanging with me on this myth-busting journey and I certainly hope it’s given you some ammunition to use back against those now ubiquitous Agile cowboys and purists that we see out there. Please comment below if you’d like a hand with any other myths you’re struggling with.

Find out more about Scrum-But versus Scrum-In-Motion by taking one of our CSM training courses.

Anyway, in this next installment we are going to be sticking with the Sprint Backlog to tackle possibly the most common operational dysfunction that we see out there, namely poor (or non-existent) Product Backlog Refinement (previously known as ‘grooming’). The manifestation of this dysfunction is multi-pronged including long, tedious Sprint Planning sessions and iterations that seriously go off the tracks, via frequent chopping and changing.

One of the core reasons for this is the myth that because we have cross-functional teams working together it follows that we need to swarm on a requirement end-to-end in a Sprint, which further implies we have to perform all of the relevant activities to complete the requirement all in the same Sprint. In other words for any given Product Backlog Item we need to do the functional design, technical design, test design, development and testing all in the one (and same) Sprint.

So here’s the rub; functional design is often very subjective requiring socialization with external stakeholders and this can lead to a certain amount of unpredictability.

Trying to include this level of ambiguity within the Sprint that you are actually trying to implement the solution will often lead to delays, waste and confusion. The trick here is to ensure that the Product Owner in conjunction with any other supporting designers (within the team) and stakeholders (outside of the team) needs to be forging a little bit ahead via the activity known as Product Backlog Refinement to ensure that Sprint-Ready items are being fed into Sprint Planning for implementation consumption.

What does Sprint-Ready look like? Well that is where a well-formed Definition-of-Ready (DoR) comes in which acts as the entry-criteria for any Product Backlog Item wishing to make it into the next Sprint Planning session. Some key high-level points to include in any team’s DoR include:

• Technically feasible
• Specific and clearly understood by the Developers
• Can fit into the Sprint
• No external dependencies

Now we certainly don’t want Product Owner’s to be too far ahead with Sprint-Ready PBIs as this can lead to other issues of waste and rework, but being one or two Sprints ahead is very healthy and reduces the potential ambiguity. This doesn’t mean that they work in a separate team, or in a ‘different’ Sprint but it does mean that their focus is split in any given iteration between supporting the programmers and testers in their efforts to complete the next validatable increment while also focusing on preparing Sprint-Ready requirement items for technical delivery in the upcoming Sprint.

Bottom line is that we want the requirements to be fit and healthy before consuming them in Sprint Planning. Thinking a bit ahead is not just common sense but frankly it is mandatory to avoid the dysfunctions of the ‘all-in-one’ approach when your team has to work with external groups.

Onto the next one!

Once again, I thank you my fellow mythbusters for joining me on the eleventh leg of our truth-revealing journey. See you next time!

If you liked this article, you can:
Subscribe to this RSS feed!

Find out more about Product Backlog Refinement by taking one of our CSPO training courses.

I thought we’d start off the year with what I’d consider to be one of the most toxic and prevalent myths that I see out there in the Agile world that leads to some seriously dysfunctional thinking.

So, a question that I get asked a little too often for my liking goes a little something like this: "If my team does not complete everything that they committed to in the initial Sprint Backlog then is this what we should call a failed Sprint?".

For me, that is an overly simplistic way of looking at the situation and ties back to what I was speaking about in part 6 when referencing the Sprint Burndown chart.

Myth origins

To tackle this one let’s explore where the myth found its origins. Back in the day, the Scrum Guide spoke about the initial Sprint Backlog as being a Sprint commitment. We can trace the etymology of the word commitment (in the Scrum context) by going back to Ken Schwaber’s early Scrum book where this term was broadly introduced, the intent of the word commitment was that the "team committed to do their best". However, over time, this word commit took on another meaning in many parts of the so-called Scrum world with many misinterpreting it to mean a commitment etched in stone which if not delivered upon would indicate a failure worthy of medieval torture!

The simple fact of the matter is that there is only one time that we have perfect knowledge about any particular requirement. And when is that? Well it is when it is completely done and dusted. As such, based on this premise, even a plan for a short ten-day period is susceptible to unknowns and this gives rise to reality, that being a plan can never be a guarantee of the future.

So to address this in part, the latest Scrum Guides have deprecated the word commitment using the less misinterpreted term of forecast. But nevertheless some people really need to be able to categorise a Sprint into success or failure. So, I actually give them a different definition of failure that they can apply if they feel they must, because I actually do believe that there is such a notion as a failed Sprint.

80% complete can mean very different things...

So let’s paint two scenarios: A team during Sprint Planning forecasts that they will complete five Product Backlog Items. Now during the Sprint they work hard but a few things go wrong and they end up nearly finishing all of them. In fact all of the PBIs are roughly 80% complete.

Let’s now switch to another team that also predicts that they will complete five items. They work hard, and again a few things pop up that weren’t expected, resulting in the fact that they only ended up completing four out of the five PBIs. Both teams did not achieve what they had forecasted and in fact, both teams only completed 80% of their target, yet in my eyes, only one of them failed. Do you know which one? That’s right. The first team failed. Why...? Well because at the end of the Sprint the first team delivered NOTHING that was potentially shippable and/or validatable when they certainly could have. If this team had swarmed just a little bit, they most certainly could have completed at the very least a few of the Product Backlog Items in the same way that the second team did.

Less starting and more finishing!

Starting lots and finishing nothing when there was the opportunity to finish at least something is the definition of a failure for those so determined to use that word. The team that only finished four out of five, at least worked together to finish four potentially shippable increments. For me this is not a failure. Sure this team should use their Retrospective wisely to determine why they were unable to achieve what was forecasted in an attempt to learn for the future. Perhaps there was something that they could improve upon and perhaps not (for example if a couple of team members were sick for a few days or similar).

Now don’t get me wrong, we certainly want to do our very best to deliver what was forecasted but we should not do this at the cost of underachieving.

Let me give you an example. If you said to a team that each member would receive a significant bonus if they are collectively able to constantly deliver on exactly what was forecasted in the original Sprint Backlog then what would happen? I’ll tell you what would happen. You would get exactly that. Beautifully packaged up Sprints that mirror the Sprint Backlog forecast exactly to the hour.

But what else would you get? You would start to generate a team that thinks so conservatively that effort will not get maximized and the team will never leave their comfort zone for fear of over-extending and not delivering. Is that what we really want? Teams that play it safe and create inordinate amounts of buffer to make sure that an artificial target is met is certainly not what I’m after in a great Agile team.

The real point of the Sprint Backlog

I want to use the Sprint Backlog as a guide and a way for us to focus our planning for the near horizon, as well as a way to work out how as a team we can swarm to deliver product increments sooner and more effectively. The closer to the forecast the better as it hopefully means that we understand our problem space well, but this should not be at the cost of the team giving sandbagged estimates full of caution.

The reality is that I don’t want my teams delivering to their forecast 100% of the time. If I see this occur, it means that effort isn’t being maximized and there is probably a culture of fear. Hitting the forecast most of the time, even with a mature team is good enough for me.

[画像:scrum myth]

Sometimes it will be over, sometimes it will be under, but so long as we are doing our best to anticipate reality and we are using our Retrospectives to continuously learn from what goes well and what does not necessarily go according to plan, then I’m generally happy 🙂

Onto the next one!

Once again, I thank you my fellow mythbusters for joining me on the tenth leg of our truth-revealing journey. See you next time when we tackle the next Scrum myth!

Find out more about planning Sprints by taking one of our CSM training courses.

Back then this was revolutionary: "What! You mean I get to see something after 30 days instead of waiting 12 months!?" was the common exclamation made by highly-excited POs. Of course since those early years, Scrum has incrementally evolved and nowadays I don’t know any teams that still run with long-winded 30-day Sprints. One-week or two-week Sprints are now the norm. Further, even waiting until the end of one of these shorter Sprints to validate with a PO isn’t ‘Agile’ enough anymore due to the super fast-paced, rapidly fluctuating environments that we now find ourselves in.

We expect Product Owners to be closing feedback loops frequently and on a day-to-day basis rather than on a Sprint-to-Sprint basis. So, these days, the primary aim of the Sprint Review is to engage with the broader stakeholder community, who, unlike the Product Owner isn’t involved on a daily basis with the Scrum team. Further, there should be no surprises for the PO in the Review as he or she should have seen any complete Product Backlog Items as soon as they were completed via a practice commonly known as a ‘Walkthrough’.

Now, while a Walkthrough is not yet regarded as a core Sprint activity, it has certainly become a generally accepted Scrum practice or GASP as Mike Cohn would put it. Think about Walkthroughs as mini-progressive Reviews that occur within Sprints, whenever a Product Backlog Item is deemed to be ‘Done’, ensuring that feedback loops are closed as soon as possible.

However, there is certainly a risk with this heightened visibility and validation, and that is the situation that occurs when the Product Owner, after enjoying a "taste test" during a nice early Walkthrough, decides that he or she wants to adjust the "flavour" of the requirement so to speak, (and I’m not just talking about a pinch of salt either!). This will naturally occur and should be expected. As such, it is important (especially in the early days of a Scrum team’s initial implementation) to include the ScrumMaster during the Walkthrough to adjudicate in case the intent of the planned, protected Sprint, is subverted, but still allow provision for minor tweaks to be absorbed by the developers. Bottom line is that although minor adjustments to the intended scope should be accepted and expected, significantly changing the requirements of a requirement due to its early visibility should be avoided unless absolutely necessary so that focus is maintained and disruptions avoided.

Happy holidays!

So we will leave it at that for 2015 and wrap up this epic journey in 2016. Thanks for following along and please have a very safe and relaxing break everyone ????

If you liked this article, you can:
Subscribe to this RSS feed!

Find out more about Sprint Reviews and walkthroughs by taking one of our CSPO training courses.

Whether or not it actually goes to a production environment or not is a commercial decision made by the Product Owner (in conjunction with any outside stakeholders) and this release decision is more often than not decoupled from the actual Sprint cadence. Some teams do try to release to production at the end of every Sprint although most teams that I work with end up releasing to production less often then that even though they still work in disciplined Sprints. They work in these time-boxes to maintain focus, limit work-in-progress (WIP), simplify planning and ensure that their product stays in a state of readiness to build confidence in anticipation of a production release whenever the time is right.

At the other end of the scale, I also work with teams that need to (or want to) release to production so frequently that they cannot wait until the end of even a one-week Sprint! These teams have such mature test automation practices, decoupled architectures and closely aligned technical environments in place that they can implement continuous delivery (still rare but becoming more prevalent). And this leads me to the second part of the myth, that being: "Scrum is no longer agile enough" as it mandates that you must wait until the end of the Sprint to release to production. Again the same principle as before applies – the releasing to production should be decoupled from the Sprint cadence as there is nothing stopping a team from using Scrum to practice continuous delivery. There is no rule stating that you must wait until the end of the Sprint to release. Scrum simply says that the aim of the Sprint is to at LEAST have something that is potentially shippable i.e. validatable and demonstrable by the end of the Sprint to mitigate risk and to build confidence along the journey.

Once again, I thank you my fellow mythbusters for joining me on the eighth leg of our truth-revealing journey. See you next time when we tackle the next Scrum myth!

If you liked this article, you can:
Subscribe to this RSS feed!

Find out more about Potentially Shippable Increments by taking one of our CSM training courses.

Let’s now go to the beginning of a project and focus on a misconception that I come across when teams are kicking off their first Agile project. This is a myth that focuses on the concept of ‘Sprint Zero’.

I’m pretty gentle on the ‘Sprint Zero’ terminology in my book and since it was published I’ve really learned to dislike the label as it inadvertently leads some to perceive Scrum as a framework that can only be used for small, trivial projects.

Let’s just go back a step and make sure that we’re all on the same page with the intended message of this term. Firstly, contrary to popular belief, ‘Sprint Zero’ is in fact not an official or mandated Scrum activity (or term) and is certainly not mentioned anywhere within the Scrum Guide. ‘Sprint Zero’ is actually a reference to the potential work that needs to occur before embarking on the first so-called delivery Sprint. As such, it really falls outside of the scope of Scrum. Now just because something is out of scope, it doesn’t mean that it’s unimportant and should be ignored. Personally, I’m a believer that there needs to be a pre-Sprint inception period that covers off certain preparatory activities such as, vision generation, formulating the initial Product Backlog, forming the team and sourcing environments.

What I don’t like about the term ‘Sprint Zero’ is the perceived coupling with a very specific timeframe, that being the length of a typical development Sprint. For example, assuming you’re running in two-week Sprints, then the misconception follows that this inception-type activity should take strictly two-weeks. The reality is that while I certainly prefer this inception activity to take as little time as possible (to ensure that the team can start building and validating business value ASAP), depending on the size and complexity of the product, this period of time may require longer than two weeks, or, for more trivial applications, it could take less than two weeks. Fact of the matter is that this inception activity and timeframe needs to be fit for purpose and flexible. There shouldn’t be the perception that you can, or should fit everything within, a ‘standard’ Sprint duration.

Onto the next one!

Once again, I thank you my fellow mythbusters for joining me on the seventh leg of our truth-revealing journey. See you next time when we tackle the next Scrum myth!

If you liked this article, you can:
Subscribe to this RSS feed!

Find out more about Sprint Zero by taking one of our CSM training courses.

Now there is one last contentious artifact that many believe is core to Scrum, and this is the Sprint Burndown. Now in the past this artifact that is used to track the daily progress or burnrate of the tasks in a Sprint, did in fact form a part of the core Scrum definition, but it has subsequently been deprecated. This is because in certain types of organisations, this tool ended up becoming an unfortunate aide for micromanagement…

Just quickly, let’s run through how it works. Teams would tally up the duration of their collective Sprint tasks and track this on the y-axis. Then for every day of the Sprint they would track how many collective hours remained for the tasks either still in progress or not started.

Following Sprint Planning, many teams would typically draw a straight, diagonal (theoretical) line, from the top of the y-axis values to end of the x-axis values, and use it as a benchmark for the actual burndown line.

The problem with this line is that Sprint progress rarely mirrors the theoretical line on a day-to-day basis.

Many Sprint Burndown lines actually burn up for the first few days because of new discoveries, before beginning its downward descent as the team gathers momentum. By including the theoretical line, a curious stakeholder may get the misleading impression that the team has fallen behind after only a day or two. Then you start hearing comments such as: "You guys suck, you’re already behind and you’ve barely started!" This in turn leads to beautiful looking charts that appear like this.

Whenever I see something like this I immediately know that the culture of this team is unhealthy, and people are either too scared to report reality, or estimates have been padded considerably.

It’s not all bad

That being said, I do find that the Sprint Burndown can be helpful to help galvanise the team (believe it or not). For example, if the team sees that it is tracking behind schedule it can be a useful reminder to focus on how the team can better swarm so that come the end of the Sprint, at least some of the Product Backlog Items stand a chance of making it to ‘Done’, rather than having them all left as works in progress. Further it can be useful to give an early gauge of whether the team is tracking ahead of schedule to trigger the Product Owner into getting a move along with any outstanding Product Backlog Refinement activities.

The bottom line is that while the Sprint Burndown is no longer a core Scrum element, it does have its benefits but it should be used very cautiously to avoid abuse.

Onto the next one!

Once again, I thank you my fellow mythbusters for joining me on the sixth leg of our truth-revealing journey. See you next time when we tackle the next Scrum myth!

If you liked this article, you can:
Subscribe to this RSS feed!

Find out more about Sprint Burndowns by taking one of our CSM training courses.