We’ve also included the instructions for the game below.
If you are interested in using games to help your Scrum teams, we discuss the topic on our latest episode of The Board, The Board – Episode 6
—————–
The rope game
Time:
3 to 7 minutes
Materials
6 to 10 people –> to form the circle
1 person to stand out of the group
1 metre piece of rope, per person in the circle
How to play
PART 1
Ask one person to volunteer to be a “Project Manager” and step out of the team.
Have the team form a circle (facing in).
Give each team member a rope and ask them to hold it in their right hand and pass the other end to a person standing across from them.
Ask each person, in turn, to pass their ropes across in the same manner until everyone is holding two ropes.
Ask the Project Manager to direct the team so that it is untangled and standing side by side in a circle.
We normally allow them a minute to a minute and a half until we stop the exercise
PART 2
Get the team to form a circle again
Ask them to repeat handing across the ropes to re-tangle themselves.
This time, ask the Project Manager to simply observe and not say anything
Ask the team to untangle itself (typically takes between 20 to 40 seconds)
Learning
This exercise demonstrates the power of a team’s ability to solve complex problems when they collaborate. It resonates with Scrum in that you encourage the team to be self organising to get the full benefit of their abilities.
If you try the game, please let us know how it went in the comments below!
On Thursday and Friday October 4 and 5, Boost closed its doors for an all-hands two-day product development workshop, to build a new tool we call Scrummaker. This series of blog posts records the two days: what we made, and how we did in.
A little context: Boost is a team of designers, developers and Scrum Masters, who have been working with Agile for the past six years or so. As well as building websites and custom software and offering Scrum services and coaching from our Wellington office, we’ve recently opened an office in Shanghai offering Scrum training and coaching. Nathan Donaldson is Boost’s managing director and the Product Owner for Scrummaker.
As part of the whole Scrum ethos, I’m timeboxing the writing of each of these posts to 20 minutes, so if the brevity leaves you curious, feel free to get in touch for more detail.
Customer validation: the research process behind Scrummaker
Customer validation has been at the heart of this project. It’s actually seen us take a completely different direction to the one that, three short weeks ago, we thought we were moving in.
Originally, we’d considered building a tool to solve one of our own pain points: turning stories in Pivotal Tracker into physical objects for sprint planning and visible workspaces. At the moment, our Scrum Master or our Office Manager spend a not-insignificant amount of time each week pulling stories out of Pivotal Tracker as CSVs, dropping them into project templates in Pages, tidying them up, then printing and trimming. We’d identified this as a pain point and poor use of our time, and considered building a tool that would integrate with Pivotal Tracker and automate this as much as possible.
We used two frameworks to conduct and capture our customer research. One was Lean Launch Lab, a product that helps you store and visualise your customer research. The other was the Validation Canvas from Lean Startup Machine, a simple one-page format for displaying assumptions, hypotheses, and pivot points.
Validation canvas for Scrummaker (from Lean Startup Machine)
We conducted research in a number of different ways. The most complex was using unbounce to set up a landing page for our theoretical new product. We used LinkedIn advertising to promote the page, and tracked conversions from people visiting the page to following a call to action to sign up or find out more. We ran a poll through the LinkedIn Scrum Practitioners group, and we also conducted a series of email and face to face interviews with Scrum practitioners in Wellington and around the world.
What our customer research rapidly showed was that our ‘printing out stories is a pain in the ass’ sentiment wasn’t widely shared. (Perhaps, being a design-led company, we worry a tad too much about everything looking good as well as working well.) Instead, what emerged was a cluster of concerns around retrospectives:
they aren’t always valued by teams and/or organisations
they are hard to run with distributed teams
it can be hard to generate actionable improvements
it can be even harder to track whether these actions are taken and what the outcomes are.
Some market research showed us that few tools already exist to tackle these problems. At this point, we felt confident that we had a good problem to solve. What could we build that would help Scrum teams run efficient and valuable retrospectives?
On Thursday and Friday October 4 and 5, Boost closed its doors for an all-hands two-day product development workshop, to build a new tool for teams running Agile retrospectives that we’ve named Scrummaker.
The purpose of the workshop was three-fold. We wanted to build a new product. We wanted to build a new product as a team. And we wanted to build a new product as a team using the Agile practices we’ve been working with now for about six years.
We’re now publishing a series of blog posts to record the two days of product development: what we made, and how we did in. The blog posts are only the beginning; we also had a crew of student filmmakers along for the two days, recording all the goings-on for a short documentary.
The first posts will cover the project lead-in: customer validation of our product ideas, the experience mapping workshop we ran to generate the user stories for the product backlog, the time-boxed technical discussion the team held to ensure we’d hit Thursday morning ready to work. There’s a post on the project kick-off, and then the meat of the series: what we learned from two days of compressed Scrum, and the product we came out of the end of the process with.
So grab a cup of whatever makes you happy and settle in for the read ….
In a recent post I discussed the question “Are user stories the same as use cases?”. This is a question that frequently arises in our Writing Great Agile User Stories workshop, and it’s often asked by business analysts. I’ve also been in Agile/Scrum training courses with BAs, who at a certain point in the day start worrying about where the BA role fits in a Scrum project.
The quick answer is: there is no Business Analyst role in Scrum – just like there isn’t a DBA role or a SysAdmin role or a designer role. You’re either the Scrum Master, the Product Owner, or part of the Scrum Team. There also isn’t a space carved out for a person to be responsible for requirements gathering and reporting.
The longer answer is that there’s still a lot of work in a Scrum project for a good BA to do. As Roman Pichler puts it:
what’s left to do for business analysts in Scrum? I have seen business analysts working as team members as well as taking on the product owner role successfully. In both cases, though, the individuals experienced a change in their daily work. Business analysts working as a team member often support their peers in product backlog grooming activities. As the business analysis activities are now carried out collaboratively, the business analysts often have time to take on other responsibilities, for instance, working with the testers or the technical writer. As a business analyst working on the team, you should hence expect to pick up new skills, broaden your expertise, and be open to work in new areas.
One small case-study
I recently worked on a short (6-sprint) Scrum project that had a nearly full-time BA allocated as a resource to the team. (Don’t you love that kind of phrasing? “allocated as a resource”. Savour it.)
We were creating a mobile interface for a cut-down set of the functionality available through our client’s current website. Our team was made up of a mix of our client’s staff and Boost staff: a Product Owner, the BA, two developers and a tester from our client; a Scrum Master, designer and me doing the wireframes from Boost.
Here’s what our BA did:
Working with the product owner
Research for writing user stories (usually by confirming how the current system works, and where there was and wasn’t flexibility to make changes)
Meeting with other parts of the business to explain what we were doing and what we needed, and to find out what they were doing and how that might affect what we were making.
Working with the team
Ferreting out system documentation
Getting screenshots of the system that I (working outside their network) couldn’t access, and reviewing wireframes with me
Helping write and QA’ing test cases
Getting wording signed off by other parts of the business (always harder than you think it’s going to be)
Getting approval from other parts of the business for use of a third-party plug-in.
Our BA attended all the planning meetings, retrospectives and stand-ups. Her work was managed just like the rest of the team’s: written as tasks and posted on the Scrum board. What she didn’t do was write requirements or use cases, or reports. There was huge value in having her on the team: she was our go-to person for all the tucked-away documentation and hard-to-find system descriptions.
Further reading
A four-part article based on a roundtable discussion amongst a group of Agile experts (including Alistair Cockburn, Roman Pichler and Ken Schwaber) on business analysis and Agile
TL;DR – User stories aren’t use cases. By themselves, user stories don’t provide the details the team needs to do their work. The Scrum process enables this detail to emerge organically, (largely) removing the need to write use cases.
Are user stories the same as use cases?
When running our Writing Great Agile User Stories workshop, I’m frequently asked “So – are user stories the same as use cases?”. Often it’s a business analyst who asks the question; they’re accustomed to working with use cases, and are wondering where use cases fit in a Scrum project, and if they’re replaced by a user story.
Looking around the web, there’s consensus that use cases and user stories are not interchangeable:
My standard answer is that user stories are centred on the result and the benefit of the thing you’re describing, whereas use cases are more granular, and describe how your system will act. And then I say “Just bear me – it will all be clear in soon”. But I thought it was time to dig further down into this.
Use cases and user stories
Let’s start with some definitions.
A user story is a short description of something that your customer will do when they come to your website or use your application/software, focused on the value or result they get from doing this thing. They are written from the point of view of a person using your website or application, and written in the language that your customers would use. A user story is usually written using the format canonised by Mike Cohn: As an [actor] I want [action] so that [achievement]. So, for example: As a Flickr member, I want to set different privacy levels on my photos, so I can control who sees which of my photos.
A use case is a description of a set of interactions between a system and and one or more actors (where ‘actor’ can be people, or other systems: for example, both online shoppers and PayPal can be actors). They are usually created as documents, and generally include this kind of information:
Use case title
Rationale/description/goal
Actor/user
Preconditions (the things that must have already happened in the system)
Standard path or Main success scenario (what will usually happen, described as a series of steps)
Alternate paths or Extensions(variations on the above/edge cases)
Post conditions (what the system will have done by the end of the steps).
At first blush, use cases look like a much better way of writing requirements than user stories. How will a team be able to implement something as wafty as As an [actor] I want [action] so that [achievement]. So, for example: As a Flickr member, I want to set different privacy levels on my photos, so I can control who sees which of my photoswithout some rigorous use cases to detail the requirements for the system? And that’s usually the point when someone in the workshop asks that question.
Writing use cases to flesh out user stories in Agile projects is certainly not unheard of (see here, and here). But it becomes clear as we move through the workshop that user stories are just the start of a process of understanding what the team is making that, by the end of its course, covers off everything a use case would have told you, but in an organic manner.
Acceptance criteria
User stories aren’t just single sentence affairs. The product owner also writes acceptance criteria, which define the boundaries of a user story, and are used to confirm when a story is completed and working as intended. For example, if this is your user story: As a conference attendee, I want to be able to register online, so I can register quickly and cut down on paperwork, the acceptance criteria could include:
A user cannot submit a form without completing all the mandatory fields
Information from the form is stored in the registrations database
Protection against spam is working
Payment can be made via credit card
An acknowledgment email is sent to the user after submitting the form.
Writing the acceptance criteria is the first step of fleshing out the details of your user story
Sprint planning meetings
In the sprint planning meeting, the product owner presents the user stories from the top of their product backlog (ie. their highest priority features) and the team commits to the stories they will complete in the sprint.
As the product owner presents the stories, the team will ask questions to further clarify the user story and the acceptance criteria. Assumptions will quickly be confirmed or corrected, and any ambiguity about the requirements starts to disappear.
This assumption and ambiguity erasure continues as the team estimates the stories (if five people on the team rates a story as a 2, and one person rates it as a 5, there’s probably some questions that need answering). And it’s repeated again as the team writes the individual tasks for each story.
Standups
We’ve been fortunate in our Scrum projects, in that our product owners generally commit to attend the team stand-up. This is another chance for the team to ask questions, and also to make the product owner aware of restrictions, issues and opportunities are appearing as the story progresses.
Wireframing
I do the wireframing for some of our projects, and usually I start by talking to the product owner about the story, and sometimes making some paper or whiteboard sketches. I turn these into wireframes and then there’s normally a couple of quick iterations with the product owner as we ask each other questions, get feedback from other people, and hopefully squeeze in some user testing.
More recently, I’ve started reviewing the draft wireframes with the designers and developers working on the story. This helps flag up any questions they have, or restrictions I might not have been aware of. After the wireframes are approved by the product owner, I’ll brief the designers and developers again if needed.
Design and development
Although most of the details have been thrashed out during the wireframing more can crop up at this stage, and there are often more questions for the product owner about exactly how they want the backend of the system to behave. Pair programming is useful here, because two sets of eyes on a piece of functionality mean yet more questions and clarifications.
No user story is submitted for acceptance by the product owner until the acceptance criteria are satisfied and the definition of done is met.
Overall
This might sound like a lengthy process. In reality, it’s just what a Scrum team does all day. Rather than one person labouring over the use cases, the team works together to surface and satisfy all the requirements. The product owner can refine the original acceptance criteria in response to new information throughout a user story’s progress.
And finally, in conclusion
There are exceptions, of course – and there are times when the upfront research needed for use cases is important (I’ve got a blog post brewing on this). But my advice would be: don’t start writing use cases until your team specifically asks for them. And if your team does ask for them, spend some time in a retrospective digging into what they’re not getting from your current processes (for example – are the acceptance criteria unclear; is the product owner unavailable; are you working with shitty documentation for another system). Then decide as a team how to fix the root problem.
1. The first rule of improvisation is AGREE. Always agree and SAY YES.
This rule for me is about openness and the willingness to engage with new ideas and new practices. As Fey explains it:
When you’re improvising, this means you are required to agree with whatever your partner has created. So if we’re improvising and I say, “Freeze, I have a gun,” and you say, “That’s not a gun. It’s your finger. You’re pointing your finger at me,” our improvised scene has ground to a halt.
The blue screen of death moment is any meeting is when you hear someone say ‘We can’t do that’, or ‘We tried that before and it didn’t work’ or ‘The IT team won’t let us do that’. That moment sucks away at your enthusiasm for the project and if it happens enough, drains your will to work.
A recent Scrum project I worked on had a brand new team working to create a prototype for a mobile app in six two-week sprints. At the beginning of the project, the team’s most common reaction to the Product Owner’s stories was ‘We can’t do that, because…’. This resistance was a real downer for the Product Owner. By the last sprint, the team was saying ‘We can do that by ….’, explaining what the potential issues were, and suggesting how to overcome them. The Product Owner told me this was one of the most satisfying aspects of the whole project for them.
2. The second rule of improvisation is not only to say yes, but YES, AND.
If your reply to “Freeze, I have a gun” is “Yes, you have a gun”, that doesn’t do much to advance the scene. YES, AND for Fey means not being afraid to contribute – in fact, seeing contributing as your responsibility.
When I heard this, I thought about things from the Scrum Master’s point of view. At the start of a project, when you’re the Scrum Master, you sometimes find yourself trying to coax quieter team members into joining discussions. You don’t want to have to do this for much more than a sprint or two. A team that needs the Scrum Master to help them talk about stories or solutions isn’t self-organising. The Scrum Master can however help create an environment where no-one feels afraid to contribute, and coach people to see contribution as part of their role on the team.
3. The next rule is MAKE STATEMENTS.
Fey writes:
This is a positive way of saying “Don’t ask questions all the time.” If we’re in a scene and I say, “Who are you? Where are we? What are we doing here? What’s in that box?” I’m putting pressure on you to come up with all the answers.
In other words: Whatever the problem, be part of the solution. Don’t just sit around raising questions and pointing out obstacles. We’ve all worked with that person. That person is a drag.
I took two things out of this. One was that MAKE STATEMENTS would be a handy poster to put up next to a Scrum board if your team has a tendency to turn a 15 minute stand-up into a 45 minute philosophical discussion.
The other thing was a reminder of how much I love the way Scrum lowers the threat level of decisions. When you’re responsible for a project, making decisions can be scary. Signing off the final design in a waterfall project, for example, means acknowledging that any changes you want to make further down the line will almost certainly be difficult and expensive. If making decisions is stressful, one natural reaction is to delay or obfuscate. However, when you’re a Product Owner on a Scrum project, you’re making decisions all the time. You get used to making the best decision for the moment, and understanding that if you need something to change in the future, you’ll just write another story. This lowers the threat level of decisions considerably, and helps your team a lot: making decisions is a lot like making statements.
4. THERE ARE NO MISTAKES, only opportunities.
If I start a scene as what I think is very clearly a cop riding a bicycle, but you think I am a hamster in a hamster wheel, guess what? Now I’m a hamster in a hamster wheel. I’m not going to stop everything to explain that it was really supposed to be a bike.
The lesson here for Fey is that some of the world’s greatest discoveries have been happy accidents (think Viagra). There’s a useful lesson here about being open to suggestions and discussions, rather than clinging to your original set of assumption and opinions. This is why user stories are written in terms of what and why, rather than how.
In conclusion
Firstly, Bossypants is a great read (or, if you like audio books, a great listen).
Secondly. Improv is the act of working together to build something new from a bunch of quickly generated ideas, pruning off things that don’t work and building on the things that do along the way. The more an improv team works together, the more they trust each other, and the better they know each others’ strengths and how to use them. A lot like Scrum projects, over all.
*I was recounting this to a friend over the weekend, who flummoxed me by asking who Tina Fey is. So just in case – ladies and gentlemen, Tina Fey.
Rather than covering techniques (like release planning, burndowns and sprint tasks) the guide focuses on what makes Scrum Scrum: the roles, events and artifacts, and the set of rules that bind these together.
In an introduction to the changes from the 2010 Scrum Guide, Schwaber and Sutherland compare the Scrum Guide to guides for games: rules (pass go, collect $200) are different from strategy (get to three houses as quickly as possible, because this is when the rent bumps up dramatically). They write:
The Scrum Guide is the definitive rule book of Scrum and the documentation of Scrum itself. The Scrum Guide and the rules of chess offer simply the rules on how the pieces move, how turns are taken, what is a win, and so on.
Strategies for playing Scrum or chess vary widely and are explained in many books, articles, and blog posts on the respective subjects. For those of us working on a revision to the Scrum Guide, this meant that all tips, optional practices, and techniques should be removed from this document. This was done along with refining some language to correct some long-standing misunderstandings about Scrum.
Given the Introduction to Scrum workshops we’re running at the moment, we were keen to look at the Guide in terms of how it can help us teach people about Scrum. Here are some of the passages that really grabbed us:
The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.
We often explain that a key part of the Scrum Master’s role is to clear impediments that are stopping the team from working as well as they could. Here, we like the notion that the Scrum Master isn’t just clearing blocks, they’re teaching people to proactively stop the blocks from happening.
… each event in Scrum is an opportunity to inspect and adapt something. These events are specifically designed to enable critical transparency and inspection. Failure to include any of these events results in reduced transparency and is a lost opportunity to inspect and adapt.
We’re frequently asked whether all the events in Scrum (stand-ups, planning meetings, task estimation, demonstrations, retrospectives) are really necessary. We usually say that of course you should use the structure and methods that suit you best – but that if you’re not following the Scrum events, you’re not using Scrum.
We also try to explain how you can go through the motions of Scrum events without getting the benefits. Thinking of every event as an opportunity to inspect and adapt, and to create transparency, reminds you of why these events are held and the spirit in which people need to participate.
A Product Backlog is never complete. The earliest development of it only lays out the initially known and best-understood requirements. The Product Backlog evolves as the product and the environment in which it will be used evolves. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful. As long as a product exists, a Product Backlog also exists.
The Scrum Guide’s section on the product backlog really emphasises that the product backlog isn’t there just to get you to an initial release – it is a long term commitment. In fact, the Guide states that the product backlog will become ‘larger and more exhaustive’ after launch. Interestingly, the Guide also dwells on the role of team members in contributing to product backlog grooming, not just the product owner and stakeholders/subject experts.
Overall, the 2011 Scrum Guide is concise (a slim 16 pages), focused and a useful resource for newbies and experienced Scrum practitioners alike. Enjoy!
More reviews of the differences between the 2011 Scrum Guide and earlier versions:
In Scrum, the definition of done tells us when a feature is completed to a releasable standard. It sits above the individual acceptance criteria for each user story. For example, here’s the definition of done for development stories from one of our projects:
committed to source code repository
passes appropriate tests for story (including cross-browser testing)
tests written and run on integration server
accepted by product owner on UAT (unless story asks otherwise)
documented (well-commented)
cross- browser testing of interface elements
readme updated if applicable
change log updated
Adding the definition of ready to the definition of done
Recently, we’ve been looking at the definition of ready – the criteria a user story has to reach before it can be handed over to the team. You can think of the definition of ready and the definition of done as two key points in the sprint cycle – one defines when a story is ready to go in, and the other defines when a story is ready to come out.
Jeff Sutherland and Carsten Ruseng Jakobsen have described a definition of ready as a simple concept that depends on discipline and creates stability in a sprint. It’s designed to stop time being wasted when it’s discovered that user stories are missing important pieces of information that means they can’t be started or completed.
A definition of ready gives the team confidence that every story they bring into a sprint is completely ready for them to get started on. In this way, as Sutherland and Jakobsen observe, a definition of ready can improve the flow and stability in a sprint.
A sample definition of ready
Here’s a definition of ready we’ve developed for one of our projects:
The business value is clearly articulated (in the format of ‘As a type of user I want some goal so that some reason‘)
The story has clear and concise acceptance criteria which describe all of the features of the story. Details are captured as a narrative texts that describe an interaction of the user and the system, focusing on the value a user gains from the system.
Once the acceptance criteria have been met the story is complete
No external dependencies block the story being completed
Story identifies external expertise and provides contact details.
Many of the points (for example, 2,4 and 5) reinforce the usual expectations of a good user story. Some are designed to trouble-shoot in advance: for example, 7 and 8 are there to help the team work as efficiently as possible, by ensuring they’re not being held up by business processes outside of the team, and have ready access to any expert help they need. And some are small tweaks that add efficiency in the longer term – for example, point 3 ensures we have a short headings for the user stories that make them easy to scan in Pivotal Tracker.
In conclusion
Of course, having a definition of ready doesn’t mean there won’t be occasions during sprint planning meetings when gaps are found in the preparation or understanding of a user story. It also doesn’t mean the team no longer has to talk the stories through with the product owner during these meetings, and throughout the sprint. But it does mean you’re creating the best possible conditions for optimal productivity in the sprint.
[Here's the tl;dr version of this blog post. Every Friday we run free workshops about Agile development here at the Boost offices in Wellington. To find out more, read on. To sign up, scroll down to the end of this post, or email [email protected]]
Here at Boost, we’ve been using Agile development practices – Scrum in particular – to run our internal projects for five years, and with our clients for three years.
We keep meeting more and more people curious about how using Agile might help their organisations. So a few months ago we sat down and developed a two-hour workshop, Introduction to Scrum, which introduces the main Agile ideas and practices, with a special focus on the Scrum techniques that we use. We tested the workshop with clients and other people, and got really good feedback.
In fact, the feedback was so good that we’ve developed and tested a second workshop, Writing Great Agile User Stories. This two-hour workshop is focused on understanding how user stories work within Scrum, and lots of hands-on practice writing user stories and acceptance criteria.
We’re now opening the workshops up to the world. There’s a workshop session available every Friday from 2pm to 4pm, and we’re alternating between Introduction to Scrum and Writing Great Agile User Stories. Further workshops are being worked on right now.
Workshop 1: Introduction to Scrum
The Introduction to Scrum workshops are run by Boost’s managing director Nathan Donaldson, a certified Scrum master.
We start off by talking about where Agile has come from, and how it’s different from traditional Waterfall development.
Then we’ll talk about the different roles in Scrum:
Product owner
Scrum master
Scrum team
We’ll cover off the core ‘artifacts’ in Scrum:
user stories
product backlog
sprint backlog
And then run you through the Scrum sprint rhythm:
sprint planning
estimation
demonstration
retrospective
After this, we’ll talk about some of the improvements we’ve seen in projects and organisations that have adopted Agile, like more communication, better specifications, less waste and less rework, better prioritisation and planning, and happier, more productive teams. And we’ll talk about the challenges that have to be overcome when Agile practices are introduced into an organisation for the first time.
And in the last five minutes we’ll run a quick retrospective on the session, so you can tell us what you liked and what we could improve. Continuous improvement is one of the core principles of Agile, and we apply it to these workshops too.
Workshop 2: Writing Great Agile User Stories
Writing Great Agile User Stories is run by Courtney Johnston, one of our project managers, a certified Scrum master and experienced Product Owner. The workshop is a focused and hands-on introduction to writing user stories and creating a product backlog.
You’ll learn
How to write user stories
How not to write user stories
How to write acceptance criteria
About Done definitions
How to create and maintain your product backlog
How user stories are estimated by the team.
As with Introduction to Scrum, at the end of the session we do a quick retrospective to figure out what worked well, and what improvements we can make.
The nitty-gritty
Who are the workshops for?
Introduction to Scrum
This workshop will be helpful for anyone involved in website and software development. We’ve had project managers, usability analysts, programmers, designers and writers attend, and everyone has found something useful in them. It doesn’t matter in the least if you’re public sector, private sector, work for a charity or a start-up, or are just plain curious.
Writing Great Agile User Stories
This workshop will be helpful for people who have already had some experience or exposure to Scrum, and who want to learn more about this particular aspect. It will be especially helpful for people new to or thinking of taking on the Product Owner role.
How many people can attend?
We cap attendees at 6 people; this is the best number for discussion and sharing experiences.
You can come along as a team – that way, you can talk about how you manage things currently, and what you’re looking to change. But we’re also happy for people to sign up in ones and twos; it’s just as useful and sometimes even more interesting to have a bunch of different perspectives in the room.
Where are the workshops held?
We hold the workshops here at the Boost offices in central Wellington. You won’t be trapped in a stuffy little room – it’s nice and spacious, with great views over Cuba Street.
What does this cost?
Nothing. The workshops are completely free, and completely obligation free.
We’re running these as free sessions for two reasons:
We really think people would benefit from using Agile methods to run their projects
We’ve learned a lot from the Wellington and international Agile communities, and want to keep the sharing going
Much of the information is targeted at people who are already familiar with Scrum and Agile, but we are well aware there are many people out there to whom Scrum is something to do with rugby, and being Agile is to do with being flexible (which I suppose is actually true either way).
As a relative newcomer to the worlds of Agile and Scrum, I’m realise there is quite a learning curve, and throughout my learning process I’ve come across a number of different resources that have helped my understanding immensely.
One of the more useful resources I have come across is the following video (and of course, the great free‘Introduction to Scrum’ seminar we run here at Boost), which quite succinctly explains Scrum in less than 10 minutes.
Of course, there is more to Scrum than this, and a number of different ideas and terms that you’ll have to remember and understand, but it’s a great way to get started.
Did you catch all of that? There is a lot of information being covered in a short period of time, and I’d recommend watching the video a couple of times to try and listen and understand all the information that is being shared.
A couple of our Scrum Masters here do have a couple of thoughts to add to the video though:
Scrum Masters and Projects managers aren’t the same thing
We like to user story points for estimation as opposed to hours
We do a burn-down of hours and a burn-up of story points
We think daily stand-ups are essential, regardless of team experience
Of course you are more than welcome to ask any questions you have about the video in the comment section below, or ask us on Twitter @BoostNewMedia or on our Facebook page. We’ve also included some of the key terms from the video below to help with your learning.
Key Scrum Terms
There are a few key terms in there that are pretty crucial to understanding Scrum, and for your benefit (and mine), here is a quick recap of some key Scrum terms using definitions from the video. Feel free to chime in with your own definitions if you have something to add:
Product Backlog: A wishlist of features you’d like to implement for your site/service/product, generally ordered in terms of business value.
Product Owner: Represents the users and owners of the site/service/product to ensure the right features make it through to the Product Backlog. They set the direction of the site/service/product.
Scrum Master: Makes sure the project is progressing smoothly, and that every team member has the tools they need to get the job done. They also remove any impediments to progress for the team.
The Team: A multifaceted group that gets the job done; includes developers, testers, and other talents as required.
Sprint: A short duration milestone that gets elements of a site/service/product to a ship ready state, taking prioritised tasks from the Product Backlog.
Burndown Chart: A chart that shows a day by day measure of the amount of work remaining in each sprint or release. Often has a Burndown Velocity line showing the trend of the project to help you understand if the project is going to be finished, early, on time or later than expected.
The Daily Scrum: A daily stand-up meeting (aka. The daily stand-up) with the team that asks ‘What did you get done yesterday?’, ‘What will you work on today?’ and ‘Are there any obstacles in your way?’.
Further Resources
Scrumology – has a great blog, and email series called the Scrum Addendum that is well worth signing up for
Simple, huh? Of course, that’s a very introductory overview, but hopefully this video makes you realise that it’s not impossible to learn, and shows you a few of the ways that Scrum can improve your development practices.
If you’ve got any questions about Scrum, let us know in the comments below, and we’ll do our best to help you. Don’t forget to subscribe to our RSS feed to keep up with our latest news and adventures, and to help you continue on your Scrum learning way.
