agile

Posts Tagged ‘agile’

January 26th, 2012

Business Analysts and Scrum projects: A short case study

Posted by courtney on January 26th, 2012

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

Colart Miles has begun a promised series on the Clarus blog

Part 1: Are business analysts the stem cells of Scrum?

Tags: agile, BA, business analysis, scrum, user stories

Posted in: Agile, Scrum

No Comments

January 18th, 2012

Use cases vs user stories in Agile development

Posted by courtney on January 18th, 2012

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:

Alistair Cockburn: A user story is to a use case as a gazelle is to a gazebo
ExtremeProgramming.org: User stories serve the same purpose as use cases but are not the same.
Mike Cohn: User stories aren’t use cases

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 photos without 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.

Further reading

Advantages of user stories for requirements – Mike Cohn

Requirements 101: User stories vs use cases – Andrew Stellman

Tags: agile, product owner, requirements writing, scrum, use cases, user stories

Posted in: Agile, Scrum

1 Comment

January 11th, 2012

Tina Fey’s Four Rules of Improv, as applied to Scrum

Posted by courtney on January 11th, 2012

Driving home for Christmas, I listened to the audiobook version of Tina Fey’s Bossypants.* Listening to her read the chapter Rules of Improvisation That Will Change Your Life and Reduce Belly Fat, it struck me that the four rules of improv that she describes translate well to the spirit of Scrum projects.

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.

Tags: agile, scrum, user stories

Posted in: Agile, Scrum

6 Comments

November 17th, 2011

My First Sprint (with Scrum)

Posted by Michael Treacher on November 17th, 2011

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!

Tags: agile, agile development, agile project management, rails, student work

Posted in: Random thoughts, Ruby on Rails, Scrum

1 Comment

November 2nd, 2011

Pair programming: When and why

Posted by Federico on November 2nd, 2011

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.

Resources

Tags: agile, agile development, pair programming, professional learning, Quality assurance, research

Posted in: Agile, Development

No Comments

August 4th, 2011

Free Friday Agile workshops at Boost

Posted by courtney on August 4th, 2011

[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

How do I sign up?

It’s easy. You can fill out an online form:

or email us at [email protected], and we’ll work with you to find a suitable date and book you in.

If you have any questions, just drop us a line. We hope to see some of you soon!

Tags: agile, agile development, agile project management, scrum, training, workshops

Posted in: Agile, Scrum

1 Comment

June 28th, 2011

Jean Tabaka on the Golden Circle of Agile & StackExchange for project management

Posted by courtney on June 28th, 2011

Last week a group of us went along to see Jean Tabaka (from Rally Software Development) presentation at a special Agile Welly Meet-up.

The event was an interactive session called Tell Me Why: The Golden Circle of Agile Transformation. Casting aside the traditional slide deck, Jean used Simon Sinek’s golden circle model to get us talking about the What, How and Why of our adoption and use of Agile methodologies. We organised ourselves into small groups and went through three rounds of discussion.

First, we talked about the what. What have we done that tells us we’re doing Agile? So, things like writing user stories and acceptance criteria, and holding stand-ups and running retrospectives – these are the practices (or rituals) that we perform when we’re doing Agile.

Then we talked about the how. How do we know which practices we should be using, or trying to improve? So things like, if a product owner keeps rejecting delivered work, maybe we need to look at the way acceptance criteria and done definitions are being stated, because there seems to be gap between what the developers are hearing and the product owner is seeing. Or things like holding regular product backlog grooming sessions, so we know we’re always working on the most important features for our product. As Jean observed, this is how you avoid getting trapped in cargo cult Agile – going through all the right motions, but not seeing the expected benefits.

In that discussion, we started digging into the principles of Agile – the why. Why is it that we and our organisations have decided to adopt Agile? For some people it was about increasing returns, or decreasing risks; for some, it was about improving the quality and timeliness of work delivered; for some, it was about team morale. Everything about your take up of Agile needs to stem from this why – if you don’t know why you’re doing something, why bother?

Back at work I started reading over the Rally blog, and found this post from Jean about being a newbie on the Project Management StackExchange. This is one of 50-plus question and answer sites on the StackExchange network, where people can ask and answer questions on specific topics. The StackExchange sites are known for their exemplary community management (and Jean’s post gives a great insight into how this works). In fact, one of my favourite Webstock 2010 talk was Jeff Atwood’s Stack Overflow: Building Social Software for the Anti-Social, about creating the first of these sites, devoted to programmers and their detailed technical questions.

Having a quick browse through the PM StackExchange, I found some interesting threads on topics like whether there’s data to show that planning poker produces better estimates than individuals, how to handle an argumentative team member, and how to avoid micro-managing a dev team. Appropriately for project management – where the job is to figure out the best system for the situation you’re in, the thing you’re building, and the team you’re working with – the answers are often opinions or sharing of experiences rather than flat-out dictums. Maybe soon I’ll quit lurking and post a question of my own.

Tags: agile, agile project management, project management, scrum, user stories

Posted in: Agile

No Comments

May 25th, 2011

Agile experiments: creating user stories with story mapping and ‘buy a feature’ prioritisation

Posted by Nathan on May 25th, 2011

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!

Tags: agile, agile development, agile project management, priorisation, product backlog, product owner, scrum, user stories

Posted in: Agile

5 Comments

May 18th, 2011

10 Great Scrum and Agile Practitioners on Twitter

Posted by Jacob on May 18th, 2011

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.

@Scrumology is the Twitter feed of Kane Mar, one of the earliest certified Scrum coaches. He retweets a whole bunch of helpful links, and also publishes a very interesting blog and an awesome email series that is well worth subscribing to.

@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!

Tags: agile, agile development, scrum, Social media, twitter

Posted in: Agile

1 Comment

May 10th, 2011

Adapting Agile’s visible workspaces to the humble to-do list

Posted by courtney on May 10th, 2011

For the past three weeks I’ve been trialling a new form of to-do list, inspired by the Agile visible workspace. It’s a literal desktop solution: it involves three pieces of tape, some Post It notes, and the right-hand side of my desk. So far, it’s been awesome. Here’s the story …

Since joining the working world, I’ve tried all sorts of ways of listing and prioritising my work: mentally (yeah, like that was ever going to work), with various online tools (always felt like too much overhead, and like I had to go somewhere to see what I should be doing), by blocking time out in my diary to focus on chunks of work (awesome, right up to the point when someone books over your work time with their meeting time) and paper lists (my favourite, but they have a tendency to breed promiscuously on my desk, resulting in archaeological layers of half-done lists doing double-time as a place to rest my damp-bottomed mug of tea).*

Over that time, I’ve found Agile visible workspaces to be the best form of to-do list for me. The whole point of the Agile board is to show what work has been committed to (through user stories), the priority of each story, the task related to each story, and the stage each story and task is at. (You can read more about how this works in our earlier post on user stories and the Agile development practice.)

Scrum Board by Drew Stephens on Flickr, released under a Creative Commons BY-SA license

My ideal situation then would be working full time on one of our Agile projects. At the moment however, while I contribute to one of our large Agile projects and run a couple of smaller ones, I’m spread over multiple projects and clients. So I started thinking about how I could adapt what I enjoy about the Agile workboard to my own case.

First I thought about what I needed. I wanted:

to keep track of the various tasks I needed to complete for each of my projects and clients
to see these tasks at all times, but not keep a whiteboard by my desk
to know what my backlog of tasks was
to be aware of which tasks were ‘blocked’ (for example, where I was waiting on client feedback before making the next set of revisions to wireframes).

I decided on a super-simple solution. I cleared some space on the right-hand side of my desk (to the right of my mouse, so firmly in my peripheral vision). I tore off three bits of blue builders tape (the kind that doesn’t mark surfaces) and used them to create three boxes on my desk top, and used a Vivid to mark these as ‘NOT STARTED’, ‘IN PROGRESS’, and ‘BLOCKED’. Then I wrote down each of my tasks on one of the smallest sizes of Post It note (5x5cm), and stuck these in the ‘Not started’ box. I tried to keep my tasks to about three hours’ work or less (so not prepare workshop but prepare card-sorting exercise; not write strategy but research governance models).

After that, I moved the tasks that I needed to work on that day into ‘In Progress’. There were about 6 of them, which isn’t ideal – not a lot of priority there. When Nathan (the boss) looked at my new visible workspace, he suggested that I try the Kanban technique of limiting how many tasks can be in progress at any given time. So I got out my Vivid and added (3) to my piece of ‘In progress’ tape.

I’ve trialled my simple visible workspace for the past three weeks. In that time, I’ve prepared and given a user-testing workshop, worked on strategy documents for two clients, worked on wireframes for one of our large Agile projects, overseen some online user-testing for a client, kept the wheels turning on two development projects, and done miscellaneous other stuff. And I’ve found my visible workspace works really well.

I can see at a glance all the work I need to do. I make decisions every morning about which tasks to move into ‘In progress’. When I’m waiting on feedback or decisions, tasks go into ‘Blocked’ (so I don’t forget about them) and new tasks move into ‘In progress’. I haven’t gone to the level of writing acceptance criteria for my stories, as I know these already.

The one thing I miss is done stars. On our big Agile boards, when a story is completed and accepted by the product owner, it gets a lovely big orange star-shaped Post It note slapped on to it during the stand-up and everyone gets to share in the glow of a job well done. When I complete a task, the Post It note gets crumpled up and tossed in the bin. The result is the same – the task moves out of the backlog of work – but the effect is certainly lacking. This reinforced for me how well Agile supports team building and team morale through very simple practices. However, having my own set of gold stars feels a wee bit over-indulgent, so I’m sticking with my more puritanical ways.

*All this makes me sound rather unfocused. I like to think that the amount I angst over my to-do lists is a sign of how much I like to be organised, not how little.

Tags: agile, agile project management, to-do list, visible workspace

Posted in: Agile

6 Comments

Boost Blog

Posts Tagged ‘agile’

Business Analysts and Scrum projects: A short case study

Use cases vs user stories in Agile development

Tina Fey’s Four Rules of Improv, as applied to Scrum

My First Sprint (with Scrum)

Pair programming: When and why

It’s not for every team

Why it’s great

How to do it

Resources

Free Friday Agile workshops at Boost

Workshop 1: Introduction to Scrum

Workshop 2: Writing Great Agile User Stories

The nitty-gritty

Jean Tabaka on the Golden Circle of Agile & StackExchange for project management

Agile experiments: creating user stories with story mapping and ‘buy a feature’ prioritisation

Adapting Agile’s visible workspaces to the humble to-do list

Categories

Archives

Boost Loves Design