As an intern here at Boost I have had the privilege of working with a group of experienced and friendly developers. I have been here two weeks now and already feel settled in completely. One of the great things about working for Boost is that everybody is very approachable when you need to ask for help or when you need things to be elaborated. This has made the transition from university to industry easier than I initially expected.
Here at Boost we use the Agile software development methodology known as Scrum. So every day I have a stand up meeting with my scrum master (Jacob Creech) and product owner (Nathan Donaldson) where I go over what I have done, what I will be working on today, and discuss problems that I need to get out of my way. So far at Boost I have been working on bug fixes for our online usability testing tool IntuitionHQ, which is built in Ruby on Rails. Working in this way has helped me get my head around the large code base that I will gradually move towards developing features for.
The IntuitionHQ Scrum Board
Using Scrum means that I’m working in ‘sprints’, or two-week long development periods. Each bug in IntuitionHQ is written up as a user story. At the start of my first sprint I took part in a sprint planning meeting which included sizing the stories (assigning them points between 1 and 8 to indicate their complexity/the effort required to fix them) and then breaking the stories down into tasks. I had to indicate how many of the stories I could commit to in the two-week sprint, and how confident I was that I could complete them in that time frame.
As an intern I was not really sure how much I could complete, being new to Rails and working in the industry in general. But one of the cool things about Scrum is that at the end of each sprint you have a sprint retrospective. This is a chance to talk about how the sprint went, and what can be done to improve things. If I don’t complete all my stories in the first sprint, the next sprint will be adapted to deal with this, and so on and so forth. So in the case that I didn’t complete all my stories it will be known for the next sprint to take on less stories in relation to their size. Overall, this is about figuring out your ‘velocity’ – how many story points you can get done in a sprint.
For my first sprint I initially committed to seven stories. I ended up completing the stories early and brought in two more stories from the backlog. One of the fun things I have found about fixing bugs is it really stimulates the mind’s problem solving abilities. I developed most of my problem solving abilities while doing my Software Engineering degree at Victoria University. Although university is a great learning environment I have found that learning in a working environment has more merits. This is because you are working with a group of people towards a common goal so they are more likely to help you out and I find that social learning is the best way to learn. This differs from university as everybody in your papers are competing to get higher grades than you so they generally don’t feed you all the facts.
One of the cool things about coming out of university into a working environment is that once you get home from work it’s your time, not stressing-about-assignments time. I believe that the less stress you have weighing on your mind the more productive you can be. Not being stressed out has helped me to be more productive working here at Boost and has got me highly motivated and keen for my next sprint. To sum up my experiences so far I would say that working here has been awesome!
Here at Boost we’ve been pair programming for a while, and seeing benefits in the form of cohesion and knowledge sharing, as well as the quality of code we produce when working in pairs. As part of the adoption of this practice I set out to research how pair programming has been working for other teams and how it can be used to improve the team dynamics.
For those that are new to the concept of pair programming: at its core, it’s when two developers sit in front of the same computer and develop code together. One programmer acts as a driver and the other as the navigator. The driver controls the keyboard and mouse and is concerned with the concrete tasks of coding, while the navigator reviews the code and thinks about bigger picture issues.
It’s not for every team
As Obie Fernandez explains in his article “10 reasons pair programming is not for the masses”, in order for pairing to work the team has to consist of developers who are committed to their work, and who are sociable and able to interact with other team members. Otherwise problems will quickly arise when you are working in such close proximity with other team members.
Why it’s great
Few or no bugs: The first thing you will notice when pair programming is how few bugs are left in code produced by the pair. Pair programming is like a constant code review process, which is why typos or small details that a single programmer normally wouldn’t notice gets spotted almost instantly by the navigator, eliminating hours of debugging later on.
Code quality: The general quality of the code is also greatly increased. This is because while the driver is implementing the logic, the navigator is free both to spot errors and to think about the big picture and how it relates to the rest of the code.
Programmer productivity: When working alone it is very easy to get distracted by email, twitter, Facebook, and all the things going on within the office. When working in pairs, if you were to do any of those things it would waste the other person’s time, so pair programming is a constant reminder to focus on the work.
Knowledge transfer: In an environment where developers work alone, it can be hard to share knowledge because there often isn’t a time or place to do it. Pair programming involves constant discussion and flow of ideas on how to resolve a problem, and normally a pair can come up with many different solutions to a single problem. It’s also great in situations where you want to introduce a new team member, to get them up to speed very quickly with the development practices, coding style, git workflow and other practices the developers might use.
How to do it
When: Although some of the development companies promoting pair programming suggest using it 100% of the time, in my own experience the intense focus and concentration that happens with pair programming can be draining over a full day. I suggest you pick the tasks that will benefit from having a pair work on them, rather than applying pair programming to every task.
Workstation setup: We have been using just one display, keyboard and mouse with great success but I would definitely like to experiment with two keyboards and see how the interaction between developers works out.
Rotating pairs: One important aspect is to let developers constantly change pairs, on a daily or weekly basis. This has several benefits: it helps develop a bond between the team members; the team as a whole takes ownership of the code instead of individuals; and knowledge sharing is increased by working with developers with different levels of experience and backgrounds.
[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.
Here at Boost we’ve been running Agile projects (using Scrum) internally for about five years, and with clients for more than three. Constant refinement and improvement is a key aspect of Scrum processes, and for our scrum masters in particular (myself, Gavin, Kriston and Courtney) looking for ways to tweak our projects is a big part of what we do.
One way we do this is by trying practice runs of new processes internally before we unleash them on our clients. Recently we trialled story mapping as a different way to generate user stories, and then tested two different ways of prioritising the stories into a product backlog. We learned a lot from this, and are looking forward to trying it with clients soon.
What is story mapping?
Jeff Patton has done the most to formulate the method of story mapping, and he contrasts it to the traditional ‘flat’ product backlog. Patton argues that while a flat product backlog is good for helping the team understand what needs to be done next, it doesn’t help the team see the big picture of what they’re making:
Arranging user stories in the order you’ll build them doesn’t help me explain to others what the system does. Try handing your user story backlog to your stakeholders or users when they ask you the question “what does the system you’re building do?”
For my money, trying to understand the system – the whole system – is the difficult part of software development. One of the most common complaints I hear from Agile teams is that they lose the big picture – that is if they ever had it in the first place.
… [A] story map arranges user stories into a useful model to help understand the functionality of the system, identify holes and omissions in your backlog, and effectively plan holistic releases that delivery value to users and business with each release.
Occasionally on our Agile projects we’ve run into the problem where, although we’re working in order of priority and regularly delivering new functionality, it still feels like that new functionality isn’t building into a cohesive whole for users. We decided to try out story mapping to see if it might help in these situations.
Generating the stories
For the trial we had:
the four scrum masters (me, Kriston, Gavin & Courtney)
a big empty wall
some builders tape, lots of Post It notes, and a bunch of Sharpies
I facilitated the story mapping, and Kriston, Gavin and Courtney took on the role of the team. Gavin was our Product Owner, and Kriston & Courtney played the part of topic specialists, there to advise the Product Owner on business and user needs. (Any combination of people could form the team for this exercise, but it’s important to make sure that the Product Owner continues to be the person making decisions about priorities based on business value, with everyone else there to advise and support them.)
The scenario we used was imagining we were going to launch an online card-sorting tool to complement IntuitionHQ, our online usability testing tool.
First, I asked the Product Owner ‘What will people do with this tool?’ (this is a more user-focused way of asking ‘What will our software do?’). The team brainstormed the high-level activities:
manage the site (admin features)
open and manage an account
create and distribute a test
display results
The Product Owner wrote each of these down on Post Its and and placed them in a row above a strip of builder’s tape on the wall.
Next I got the Product Owner to brainstorm the user stories that fell out of each activity, and stick them up in columns under the related activities. For example, under ‘Open and manage an account’, we had the user story As a IntuitionHQ customer, I want to log into the cardsorting tool with my existing account details, so I can get started testing quickly. We ended up with about 25 user stories across the four columns.
'Wall' with stories arranged into groups
Prioritisation 1: traditional method
At this point, the user stories were in random order in their columns. Next I got the Product Owner to order them from most to least important within their columns.
After the stories were prioritised, I got the team to work together to identify a ‘walking skeleton’: the stories from each column we’d have to complete in order to have a first release of the software that was both high value and immediately useful. We put a line of builder’s tape across each column where the cut-off point fell.
'Wall' with priortised stories
Prioritisation 2: ‘buy a feature’ method
Next we tried another way of selecting stories for the first release. We went through and roughly sized each of the stories, allocating 1, 2, 3, 5, or 8 points to each (in the real situation, we’d have the people working on the project estimating like they normally would).
Then I gave the Product Owner a ‘budget’ of $30 to ‘buy’ the stories they wanted to see in the first release (with ‘buy a feature’ prioritisation, you use a budget of between 1/3 and 1/2 the entire system budget, to force decision-making.) The ‘cash’ was in the form of small Post Its with $5, $2 and $1 written on them – so to buy an 8 point story, the team had to pony up a $5, a $2 and a $1.
'Wall' with stories prioritised by 'buying' features
What we learned
It was fascinating watching the team change their mind about priorities with this spending limit in place. For example, in the first prioritisation, the story As a IntuitionHQ customer, I want to log into the cardsorting tool with my existing account details, so I can get started testing quickly didn’t make the cut as a first release. In terms of opening and managing an account, this was originally seen as a nice to have, compared to the functionality to create a new account. When faced with a limited budget however, the team decided this was the only story they wanted to buy from the ‘Open and manage an account’ column, reasoning that for a beta release, they’d be happy to offer the site just to existing customers. This released more cash to buy the essential stories associated with creating and distributing tests, and collecting and displaying results.
Based on current and previous projects, we know that a point usually represents about three hours work. Using this technique of estimating and ‘buying’ stories, we know we’d be able to give a client a reasonably accurate picture of what we’d be able to deliver within any given budget.
Where we think story mapping will be useful
The scenario we picked – building an online card-sorting tool – was quite simple, and as we’ve built something similar we had a good understanding of what we’d need and how much work was involved. Our story mapping exercise was therefore quite straightforward, and we completed it in under two hours. In his article ‘How you slice it’ (download the PDF) Jeff Patton describes how to run a far more complex story mapping exercise. The overall goal remains the same: a useful and highly usable first release, which sets the stage for further iterations. As Patton writes in the article:
Incremental release may be one of the more valuable aspects of the various Agile development methodologies. An early release can help capture market share, generate early return on investment, and reduce money risked on software development. A strong early release can increase those benefits immensely. The model we’ve built can give you a better picture of your software’s features and help your organisation construct the most useful and coherent early release possible.
We can see a number of situations where this technique will be useful
at the beginning of any Agile project, when user stories need to be written and prioritised
particularly, at the beginning of projects where the software or product is intended to do a number of different things
when you’re working with a team that has previously felt like it doesn’t have the big picture of a project
when a product owner is finding it hard to prioritise stories for the first sprint or first release
when a product owner needs support getting stakeholder agreement on how features and stories are to be prioritised.
More background on user stories
Want to know more? Check out our introductory series
Don’t forget to subscribe to our RSS feed to keep up with all our latest news and developments, as well as a ton of great Scrum and Agile resources. Thanks for dropping by!
The internet is full of interesting resources, but sometimes it gets hard to sift through all the junk in order to find the good content. I find Twitter is really useful for this, especially if you are following the right people, because they sift through all the bad stuff before it gets to you.
Lately I’ve been learning a lot more about Scrum, Kanban and Agile in general, and I’ve discovered a number of really useful people to follow. Read on to see 10 people (in no particular order) you really should be following on Twitter if you are interested in learning more about Scrum and Agile:
10 Great Scrum and Agile Practitioners on Twitter:
@MikeWCohn wrote the book (literally) on Succeeding with Agile. He also publishes a great blog that has all sorts of interesting discussions about Scrum and Agile. Definitely worth a follow.
@ScrumAlliance is the official feed of the Scrum Alliance; an organisation set up to help promote awareness and understanding of Scrum. They post a ton of helpful resources in this area, and keep a very steady stream of great content pumping out.
@smamol is the feed of Sandy Mamoli, the head of the Wellington Agile Professional Network. She also publishes a fantastic blog about Scrum and Agile that is well worth following. She also keeps a very active Twitter feed.
@JeffSutherland, for those who don’t know, is one of the co-creators of Scrum. He regularly links to great Scrum resources from his Twitter feed, and although he isn’t the most prolific Twitterer, he always tweets interesting information.
@JeffPatton has been involved in Scrum and Agile for a very long time. You can check out his website, Agile Product Design or just follow him on Twitter to keep up with his insightful tweets.
@KSchwaber – Ken Schwaber, along with Jeff Sutherland, is one of the co-creators of Scrum. Again, not the most frequent tweeter, but it’s always very interesting to see what he is sharing. You can also follow his blog for more great information.
@JimHighsmith is one of the cofounders of the Agile Alliance, an author, and a man with a huge amount of experience working with Agile. He also regularly publishes interesting content to his blog.
@LyssaAdkins is a certified Scrum Trainer and Agile Coach. She wrote a book on Scrum and Agile Coaching, and she has a very lively Twitter feed.
@Scrum_Coach is Doug Shimp’s Twitter feed. Doug is a Certified Scrum Trainer with a very lively Twitter feed. He posts all sorts of great quotes and links to other resources. He also (periodically) writes a Scrum blog.
Hopefully that gives you some useful people to get started with in your Scrum learning quest as well. Of course, you can also follow us @BoostNewMedia or on Facebook.com/BoostNewMedia to keep up with all our latest news and developments. We share a ton of Scrum and Agile resources as well.
If there is anyone else you think we should add to this list (or when we do a ‘people to follow list 2′, be sure to let us know in the comments below. We’d love your feedback.
Don’t forget to subscribe to our RSS feed to keep up with all our latest news and developments, as well as a ton of great Scrum and Agile resources. Thanks for dropping by!
To test, in public, a prototype of a new, single UK Government website.
To design & build a UK Government website using open, agile, multi-disciplinary product development techniques and technologies, shaped by an obsession with meeting user needs.
About the site
According to the Cabinet Office news release, this is the first time the UK government has followed the normal practice of large organisations of launching a prototype test a web service and gather feedback.
At the moment, the website contains answers to the 100 most frequently asked questions in government. The site is focused on search (including search results tailored to people’s locations) and directing visitors towards high-demand topics.
it is not intended to be an instant replacement for existing gov.uk sites. Nor does it improve the quality of government’s online transactions – others are working hard to make these easier to use.
What Alpha.gov.uk does do is trial a selection of new, simple, reusable tools aimed at meeting some of the most prevalent needs people have from government online. The aim is to gather feedback on these new approaches from real people early in the process of building a new single website for central government.
It is made very clear throughout the site that this is an alpha release, and, as the strapline on every page states ‘There may be errors, inconsistencies and inaccuracies’.
If people who are not yet online can be tempted into doing just one of their (typical) 4 or 5 monthly Government transactions online, then that would save the Government – and hence taxpayers – about £1bn each year. That’s a big number.
But, equally important, a gov.uk which is so good, so simple, so hassle-free that it actually encourages people who are not online to get online will save them hundreds of pounds per year – think price comparison sites, cheap online offers etc. And many of those who are not yet online are people for whom savings hundreds of pounds can make a huge difference.
The team is a mixture of government employees and vendor/agency types: half a dozen developers, two search analysts, a product lead, a design lead, a tech lead, an editorial lead, a content strategist, an editor and a project manager.
we see our project as part of a wider cultural movement with many advocates across government, seeking far more agile, iterative, user-need-driven digital product development.
Recently here at Boost we’ve been reviewing the UK Government ICT Strategy, released in March. One of the strategy’s objectives is ‘Reducing waste and project failure’:
Where possible, government will move away from large ICT projects that are slow to implement or pose a greater risk of failure. Additionally, the application of agile ICT delivery methods, combined with the newly established Major Projects Authority, will improve government’s capability to deliver projects successfully and realise benefits faster.
Among the actions listed in the strategy are:
establish[ing] an approach and capabilities for agile delivery in government which can be replicated across departments (culture, multidisciplinary teams, risk-based testing, service-oriented architecture, product management and road-mapping)
creat[ing] a ‘virtual’ centre of excellence across government and the private sector which can enable fast start-up and mobilisation for agile projects
identify[ing] a pilot project within each department to prove and embed the agile approach
Given our focus on Agile projects and user-centred design here at Boost, we’re understandably excited to see this happening. If you’d like to learn more about Agile, we’d love to hear from you.
Today’s post is about how you can use user stories (and other tactics) to engage stakeholders in an Agile project.
It might sounds like user stories are being proposed here as some kind of magic bullet for any and all project woes. They’re not. User stories are a tool, and like any other tool, if they’re badly used or ill supported they won’t bring you the benefits you were seeking. Equally, when well used they not only underpin a very effective development process but can also be used to communicate project progress and decision points to people outside the development team (aka stakeholders).
What’s a stakeholder?
As noted in the post about the development process, in an Agile project there are three roles: Product Owner, Scrum Master and team member. Only people doing actual work are in the team. Only people who are in the team go to stand-ups, retrospectives and planning sessions. It might sound blunt, but that’s the way it works best.
I usually define ‘stakeholder’ as a person outside the team who has a direct interest in the project’s outcome. (This is another good definition.) They might be paying for the project, they might be ‘sponsoring’ the project within an organisation, they might be the people who work with the end customers. They are the people who the Product Owner needs to take direction from and report back to.
Product Owners and stakeholders
The relationship between the Product Owner and project stakeholders can be a delicate dance. Ideally, the Product Owner will be someone who the stakeholders really trust. The Product Owner is constantly making decisions for the project, and needs to have the confidence to make these without referring back to the stakeholders in each instance. Equally, the Product Owner needs to keep stakeholders advised of progress, and get sign off on any necessary decisions.
I’ve been the partner in these dances before, and I’ve learned it’s something you get better at the more you practice. Here are a few things that I’ve found work well.
Kick-off meetings
Before you start writing user stories or anything else, bring the whole team and all the stakeholders together. Get the stakeholders talking about who their customers are, and what they want to make for them.
In these meetings, we often use a variation on the project success slider tool to understand the environment we’re working in. Often stakeholders are under pressure: a limited budget, a tight timeframe, a group of customers who they need to deliver a new service to.
Project Success Slider from LibraryTechNZ
At Boost we used a modified version of the sliders, where each factor can be awarded a value between 1 and 7, but only 28 ‘points’ are available to be awarded. We find the exercise has two benefits:
Everything gets discussed out in the open, and the group has an objective and visual way of reaching consensus on what the project needs to do in order to be successful (e.g. “We’ll accept delivering beta software that’s 80% in terms of our quality criteria, if it means that we hit our deadline and we have all the functionality we wanted to get out there.”)
An understanding is reached that can be used to make decisions later in the project. Say the group decided that staying within budget was more important than the timeline. Now imagine a scenario where a key team member has to take two weeks’ sick leave a month before launch. Going back to the original values, you decide to push out the launch and wait for the team member to come back to work. If you’d decided timeline was more important than budget, you might decide to bring in a contractor to take the team member’s place to get the work done in time for the scheduled launch.
Priorities and the product backlog
I don’t advise getting stakeholders involved in writing user stories, or doing the prioritising. However, they are likely to want – and warrant – insight into what’s being prioritised and why. And you as product owner need to make sure you’re still making decisions according to the business’s needs (and that the business needs haven’t been changed without anyone telling you).
A technique that’s worked well for me in the past looks something like this. The afternoon before the sprint retrospective, but after I’ve prioritised the user stories for the coming sprint, I have a meeting with the project stakeholders/sponsors. I show them the work that’s been completed since we last met, and present anything that needs to be signed off as a milestone. I explain what I’m trying to achieve in the next sprint. Then I confirm that my priorities are still the right priorities.
I usually use Pivotal Tracker and show stakeholders a view where completed stories are presented in one column, current sprint stories in the next column, and the unstarted stories in the last column. It’s a project update in one screen. Then if they chose to reprioritise anything, they watch on the screen as I drag and drop stories around. It demonstrates very effectively the impact of these decisions on when work is likely to get done.
Demonstrating progress
Because the focus with Agile is on regularly delivering deployable software, you’re in the happy position of frequently showing stakeholders completed chunks of work. And because user stories are written in plain language, when you look at a list of completed stories it’s easy to understand exactly which features and functionality have been completed – even if you’re delivering something hard to demonstrate, like setting up a server or fixing bugs.
Between demonstrations and the user stories, I’ve found there’s rarely any need to write project update documents. It’s obvious what’s been completed, and what remains to be done. It’s also possible to see if you’re working more slowly than you expected, and therefore need to start thinking about getting more people into the team, or freeing up more of existing team members’ time for the project.
In summary
The things you’re already doing as part of an Agile project make good communication tools when you’re talking to people outside the project. You can do reporting without the overhead involved in writing reports, and you can stay within the spirit of the process. All of this helps develop people’s understanding of how web and software projects happen.
That’s all for this week. The next post will look at trouble-shooting some of the common challenges faced on Agile projects. Thanks for reading!
Last week I described the bones of the user story. Briefly, a user story is a description of an objective a person should be able to achieve when using your website/application/software, written in the following format
An an [actor] I want [action] so that [achievement]
For example:
As a Flickr member I want to be able to assign different privacy levels to my photos so I can control who I share which photos with.
This post adds some flesh to the idea of user stories, in the shape of acceptance criteria.
Where are the details?
At first glance, it can seem like user stories don’t provide enough information to get a team moving from an idea to a product.
Card – stories are traditionally written on notecards, and these cards can be annotated with extra details
Conversation – details behind the story come out through conversations with the Product Owner
Confirmation – acceptance tests confirm the story is finished and working as intended.
In a project following an Agile process, user stories are discussed in meetings with the Product Owner (the person who represents the customer for the thing you’re developing, and who writes the user stories) and the development team. The user story is presented, and the conversation starts. For example:
As a conference attendee, I want to be able to register online, so I can register quickly and cut down on paperwork
Questions for the Product Owner might include:
What information needs to be collected to allow a user to register?
Where does this information need to be collected/delivered?
Can the user pay online as part of the registration process?
Does the user need to be sent an acknowledgment?
The issues and ideas raised in this Q and A session are captured in the story’s acceptance criteria.
Acceptance Criteria
Acceptance criteria define the boundaries of a user story, and are used to confirm when a story is completed and working as intended.
For the above example, 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.
As you can see, the acceptance criteria are written in simple language, just like the user story. When the development team has finished working on the user story they demonstrate the functionality to the Product Owner, showing how each criterion is satisfied.
Including acceptance criteria as part of your user stories has several benefits:
they get the team to think through how a feature or piece of functionality will work from the user’s perspective
they remove ambiguity from requirements
they form the tests that will confirm that a feature or piece of functionality is working and complete.
