Sunday, December 29, 2013

Sprint Retrospective: The hidden key to Agile utopia


The 12th principle of the Agile Manifesto is:
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly
The Scrum Guide explicitly tells us to have a Retrospective with every sprint. However, with no real guidelines it can easily become ineffective and only done because everything must be "done".

What do I do?

It is important to remember the fundamental drive as to why a Sprint Retrospective is needed to begin with - it's to 'Continually Improve'. Hubbard explains how to achieve this in three simple steps:

  1. Collect data
  2. Derive insights
  3. Determine actions

How do I do it?

Now that we know what we want, how do we get "data" so that we can derive insights and ultimately determine actions to improve our teams? Ask questions of course. Rogalsky reminds us that "Wording matters" and it really does. Luckily for us, InfoQ seem to have got the memo on the whole "wording" thing with these 4 great questions to ask during Sprint Retrospectives:
  1. What went well?
  2. What didn't go so well?
  3. What have I learned?
  4. What still puzzles me?

Now do it!

So there you have it, the Sprint Retrospective is absolutely critical for your Sprint as it allows your team to reflect and improve, continuously.

So what's stopping you from improving yours?

Saturday, November 2, 2013

3 Reasons Why You Need a Scrum Master

A Scrum Master is:
"a servant-leader for the Scrum Team... [and] helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t." (The Scrum Guide, 2013)
So what makes this role necessary for you to have in your Scrum team? I've picked out 3 reasons that have resonated with me the most:

1. You need another perspective

While by definition Scrum teams are self-organizing, sometimes teams get a little too complacent about their pace of work. Estimations begin to get buffered too often and moving-that-story-to-the-next-sprint becomes an all too common occurance.

A Scrum Master helps keep the team in check. They do this by questioning why committed work isn't being completed. This gives the team a higher sense of accountability when someone else is trying to improve it.

2. You can't remember everything

Time-boxing, a specific amount of meetings and all the other Scrum related goodness, can be hard to adhere to and sometimes even remember.

A Scrum Master knows and enforces the theory, practices and rules of Scrum. They make sure meetings stick to their allocated time, ensure the team is being 'agile' and provide some order to the otherwise free-form art of agile software development.

3. Your own personal superhero

Impediments, blockers, bad stuff - they can't be avoided. Whether a stakeholder isn't being clear or someone from 'the business' wants to add requirements mid-sprint, nobody seems to care.

A Scrum Master makes it their duty to stop "bad stuff" from happening. They help remove blockers and make sure Scrum helps develop valuable software and that crazy dreams concocted on the 50th floor by some old-hat business person remain just there.

So what are you waiting for? Go get yourself a Scrum Master today!

Tuesday, September 24, 2013

The Definition of Done - applying Scrum in large Organizations

A.K.A. Static Acceptance Criteria

The Definition of Done (DoD) is a hard pill to swallow for some as it can seem like unnecessary work. I am here to tell you that the Definition of Done is absolutely necessary.

It's your static acceptance criteria - for any given piece of software you are delivering, these criteria must be completed so that the software is deemed "shippable to customers". At a basic level, the DoD can can include:
  • Unit tests
  • Integration tests
  • BDD tests
  • Documentation
  • Product Owner approval

The list can go on for as long as you want it to. When your DoD list is complete you know that you can ship your new software to customers. It's as simple as that.

Do I need a Definition of Done?

No, but without one all of your work will never really be "Done". If you miss documentation for a particular feature, a business stakeholder will eventually want it. If you don't write a test for a chunk of code, someone will eventually tell you that is not acceptable.

So while a DoD is not necessary, it is the same as asking if you ask if quality is necessary for your product. Is a quality product necessary for you?

Friday, September 20, 2013

Writing (Agile) User Stories using JIRA

As a follow up to my last post, I will describe how to create user stories using JIRA, an issue tracking tool.

How to: Writing User Stories using JIRA

  1. Start a free trial or buy JIRA
  2. Create a project (to store your user stories)
  3. Create an issue (a.k.a. user story) and even sub-tasks
    1. Fill out the details of the issue (see my last post for a list of fields to fill out).
  4. Track its progress (i.e. change the issue's status from 'open' to 'in progress' to 'closed')
Once you have successfully written User Story there's only one thing left to do - make sure it gets "Done".




Monday, August 5, 2013

Writing User Stories as an Agile Business Analyst


What is a User Story?

The Agile Alliance (2013) describes user stories as:
In consultation with the customer or product owner, the team divides up the work to be done into functional increments called "user stories".
There are formulas such as INVEST that help you write the stories, but I will help describe the involvement of an Agile Business Analyst in creating user stories.

As you can see in the definition provided above, creating a user story is "In consultation with the customer or product owner" which aligns to the role of a "waterfall" (BABOK) Business Analyst who is a facilitator.

What do I have to do?

It's quite simple, fill in the gaps.

 
  • Task ID - The unique number you have assigned the user story.
  • Description - A one-liner describing the user story. You will need to utilize the collective brains of developers, testers, architects and, yes, your customers to flesh this out properly.
  • Owner - The one person who is accountable for the task. Their effort may be far less than all those involved, but they must ensure that the appropriate people are involved to get the job done.
  • Story Points - The relative effort of the user story. This is discovered during Sprint Planning.
  • Impediments - Any other task or user story that may be impeding the task you have just created.

What's next?

What I have described in this post is the bare minimum that goes into creating a user story. What do you do to create user stories as an Agile Business Analyst?

In my next post I'll describe how you practically create user stories in an enterprise setting using my tool of choice, JIRA.

Sunday, July 28, 2013

Sprint Planning as an Agile Business Analyst

What is Sprint Planning?

A meeting to generate two artifacts [1]:
  1. Sprint Goal
  2. Sprint Backlog

Why do I need it?

It provides a vision and a pinch of guidance in regards to what should be achieved in the Sprint.

Most importantly, it sets out the tasks that will be worked on during the Sprint.

Who participates?

Everyone - related to the project that is.

What do I do as an Agile Business Analyst?

Liaise - it was what you were born to do.

You help decide what goes into the Sprint Backlog. Along with the ScrumMaster, you help guide the team to look at what is in your Product Backlog and to estimate what you should be able to do in the next Sprint, and thus what you will put into your Sprint Backlog. Ideally the Product Owner will help estimate, but in large organizations that isn't always feasible.

How do you estimate you ask? Be relative. Whether you are using the Fibonacci sequence, Small to Large shirt sizing, or anything in between just make sure you measure the effort of the user stories you.

In my experience, Scrum Poker (a free app for iOS and Android) helps you do this. Note, effort is estimated as the entire effort to deliver the user story, from analysis, to development and testing. A quick example of how this would play out in a work environment is as follows:
  1. Choose: Pick the relative effort value you feel the user story is worth.
  2. Show: Each team member shows all other team members their phone.
  3. Reveal: Shake your own phone to reveal your value.
  4. Justify: Those with extremely low or high values compared to the rest of the team justify why they have chosen their values.
  5. Repeat: The team repeats steps 1-4 until consensus is reached.
Don't forget about your Sprint Goal, which is:
"a given objective based on the Product Backlog that is committed to and completed by the team each Sprint"
(Agile Guidance, 2013)
In a nutshell, your sprint goal should be a generic statement that you fulfill by the end of the Sprint, because sometimes things get in the way and you can't put in all the bells in whistles. An example of this would be the Sprint Goal "Create a Log In page". You may be able to make a very basic log in page, and had a user story to make it look good, but because of unforeseen difficulties or circumstances, you could not make it pretty. But, because your team still created the log in page, the team fulfilled the Sprint Goal and thus were successful during the Sprint.

So that's Sprint Planning from an Agile Business Analyst's perspective. How do you do your Sprint Planning? Let me know in the comments below.

Sunday, July 21, 2013

Sprints in Enterprise Agile Projects (The Magic Number is 2)

So what's a Sprint?

Simply put, a Sprint is a:
"time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created"
(The Scrum Guide, 2013)

How long should I "Sprint" for?

1, 2, 3 or 4 weeks, as long as it's consistent. 

If you choose to run with a 1 week Sprint, you must ensure that for the life of your project all the Sprints run for 1 week. This also applies to 2, 3 and 4 week Sprints.

In my experience, 1 week Sprints are a bit too short for a team in a large organization to properly produce a releasable product that is adequately tested. By the time you figure out what you are going to produce, get all stakeholders on board and discuss how the solution will fit into your enterprise's current and future architecture structure, a week will easily pass. 2 week Sprints seem to hit the sweet spot.


If you have found other Sprint duration work better for you, don't hesitate to start discussing in the comments below. Get running!