Agile Stance Series Part 9 - Prioritization

This is part 9 of the series of post around Agile.

Prioritisation

With the knowledge that the Sprint Team has a good understanding of the User Stories and with the estimates that the Sprint Team provided, the Product Owner is now fully able to prioritise the Product Backlog in 1 to x order, meaning that no two User Stories will have the same priority.

The Product Owner is warned that any User Stories with the same priority will be left to the Sprint Team to prioritise.

The Product Owner starts by selecting two User Stories and prioritising one above the other. The Product Owner will then select another User Story and insert it above, below or in-between the existing User Stories. The Product Owner will continue to do this until all the User Stories have been prioritised

Agile Stance Series Part 8 - Dependencies

This is part 8 of the series of post around Agile.

Dependencies

The Sprint Team would do well to note down any dependencies between User Stories while estimating and any dependencies between User Stories and external factors should there be any.

A dependency is a task that is required to be completed before another task can either be started or finished. An example of a task that must be completed before another task starts, a door must be opened before anything can pass through it. An example of a task that must be started before another task can start could be that you need to start charging your phone before you can use it, although the task of charging your phone doesn't need to be complete in order for you to use it.

Often there are multiple tasks that need to either be started or completed before successor tasks can start or finish. This as you can imagine can get very complicated and may require a system to manage and keep on top of.

There are a number of techniques to identify dependencies including work breakdown structures, but this post is to merely suggest that using an agile methodology still means that dependencies require attention.

Agile Stance Series Part 7 - Definition of Done

This is part 7 of the series of post around Agile.

Definition of Done

During the Sprint Planning the team will be brought together to agree on a common definition of what it means for a task to be done/complete.

It is important for the team to come to an agreement of what done means to them. Remember, agile is around buy-in and not dictation. The team should discuss and decide together what equates to "done".

The outcome will be a list of checks (not to be confused with formal project acceptance criteria) that a task must pass.

Depending on the types of tasks, this might be a separate list for each team or for the different types of work package or more commonly, a single list for the entire team.

The list could include:

• code written
• code peer reviewed
• unit tests complete
• documentation complete
• integrated with code base
• other checks specific to the environment

This puts an emphasis on producing quality and the teams buy-in and commitment to the Sprint Goal.

Agile Stance Series Part 6.5 - The Roles of Scrum

This is part 6.5 of the series of post around Agile.

The Roles of Scrum

I've realised that I'm focusing more on the Scrum Methodology than any of the others, so thought it wise to briefly outline the different roles.
Although I'm sure as a reader you're not taking this as your only source of information, for a more complete view of what I'm trying to achieve with this series I feel it is necessary to define these roles.

ScrumMaster
The ScrumMaster ensures that Scrum Methodology is followed. They mediate decisions between the team and help each of the team and the Product Owner perform their duties by removing what have been termed as blockers and providing clarity on how Scrum works.

Product Owner
The Product Owner is the conduit to the business. They have are effectively the client and where the requirements come from and sign off on deliverables come from.
This is arguably the most difficult role as the Product Owner is potentially a spokes person for a wider audience of different and potentially opposing views with a variety of goals.

Team Member
This is as you can imagine the team that will work to provide deliverables. In a software project, this will be made up of analysts, designers, developers, testers and depending on the nature of the project, probably more.

Agile Stance Series Part 6 - Estimation (2 of 2)

This is part 6 of the series of post around Agile.

Estimation (2 of 2)

Planning poker is an effective estimation aid that promotes a collaborative estimation consensus between the Sprint Team. The technique involves each member of the Sprint Team making 'silent bid' (estimate) using a playing card by placing it face down. By placing the card face down, each estimate is not influenced by any others. If all estimates are the same, a consensus has been reached. If there are differing estimates, this bring conversation on what people see as being involved in the task taking the team into a deep level of understanding and ironing out assumptions that have been made.

User Stories that that cannot be completed in a single Sprint, must be broken down into smaller manageable chunks. When the second User Story is selected for estimation, it is compared to the first. If it is twice as complex, it will be allocated twice as many Story Points. If it's half the complexity, it will be given half the amount of Story Points. If it is of a similar complexity, it will be given the same amount of Story Points. The key to this technique is maintaining a consistency and estimating each User Story consistently with the previous User Stories. Maintaining consistency will allow the measurement of velocity over several Sprints. Without this consistency, the value of velocity and forecasting are lost.

The estimation will be an estimate to complete the User Story in its entirety, including analysis, development, unit testing, integration testing and acceptance. This emphasizes the concept of multi-functional teams, where each of the Sprint Team member will be required to do more than just a single task, be that task analysis, development, testing or integration. The Sprint Team is a dynamic group of individuals that are able to support each other and handle a range of tasks and responsibilities.

Agile Stance Series Part 5 - Estimation (1 of 2)

This is part 5 of the series of post around Agile.

Estimation

Once User Story concepts have been listed, the sprint team will review the User Stories with the Product Owner present and ensure that they have a good understanding of what is involved with each User Story.

During this process of going through each User Story, the Sprint Team will make a points (Story Points) based estimate of the complexity for the User Story.

Story Points based estimation is a way to purify an estimate free of extras such as padding like contingency and other additional time added to tasks. A task is what it is and is rated by its complexity rather than the time it will take to complete.

The time to complete a set of User Stories will be reported on at the end of the Sprint giving the velocity of working for the Sprint Team. This also allows for team members of different skills levels to view User Stories with the same measurement. A User Story of complexity 5 story points to a senior team member will also be a complexity of 5 story points to a junior team member. This begs the question, what is the value of a Story Point!

The value of Story Points are relative to other User Stories completed within the same project, by the same Sprint Team. Estimation is begun with a single User Story. It is rated by its complexity by a measurement between specific parameters. This could be numbers for example 1 to 6, t-shirt sizes x-small to x-large or anything that the Sprint Team has a common understanding of and inspires them. The only rules are that largest complexity rating must be achievable within a single Sprint duration and must be collaboratively agreed to by the Sprint Team.

Agile Stance Series Part 4 - High Level Prioritization

This is part 4 of the series of post around Agile.

High Level Prioritisation

With larger Product Backlogs, it's generally good practice for the Product Owner to start prioritising at a high level.

This could be a "MoSCoW" (Must have, Should have, Could have and Won't have) approach or could be that the Product Owner just selects what stands out at them as the most important User Stories to begin with.

Either way, this ensures that the more important User Stories are addressed at first.

Prioritising is incredibly important part of the Agile process. Without prioritisation the team does not have direction, delivery is not clear and value of the product cannot be visualized.

Agile Stance Series Part 3 - Testing

This is part 2 of the series of post around Agile.

Testing

Is testing different for a User Story compared to a traditional project?

The User Story will need to pass each of the Acceptance Criteria in order to pass testing and Product Owner approval, also known as User Acceptance Testing (UAT).

System Testing

There will be different levels of Acceptance Criteria for each of these purposes, for example testing acceptance criteria will include low level detail such as when selecting a new username:

• the character limits must be adhered to
• case sensitivity rules
• special character usage restrictions
• backend checks to prevent possible duplicate with existing usernames
• calls to backend database
• data validation around characters sent   

User Acceptance Testing

UAT acceptance criteria will be more around whether the requirement meets the Product Owners expectation from their vision and the actual business need.

Agile Stance Series Part 2 - User Stories

This is part 2 of the series of post around Agile.

User Stories

Within a Scrum project, requirements are gathered for the project in the form of User Stories. A User Story is a concept for a requirement. A User Story is not meant to be a detailed document negating the need for any further communication, more so, a User Story is a talking point and placeholder for further information to be gathered.

A User Story is commonly written in the following form:

"As a {user type}, I want to be able to {action/goal}, so that {beneficiary's reason/value}".

For Example

"As a Manager, I want to be able to review actions made on a document, so that I can report  on the number of documents progressing between statuses".

This alone is not enough information to develop a requirement, but it is enough information to engage the product owner and learn more.

Each User Story will also have Acceptance Criteria associated with it, but that's another... story!

Agile Stance - A series of posts on Agile and Scrum

I'm going to write a series of posts around Agile and specifically Scrum and keep this page updated as a table of contents for all the posts in this series.

This is to help me aid and direct people for learning purposes and (to shamelessly use the pun), I'm going to keep the posts Agile and evolve them when and where necessary.

I'll start with a quick intro...

Agile is an approach that was originally created for software delivery and now widely used across a number of industries and in a blog I read a good while ago was used to effectively organise a family holiday.

It is an approach that uses iterations or cycles of a fixed amount of time to openly and clearly delivery a successful product rather than to just complete a project. This allows the product requirements to change during the course of the project (not the course of a iteration/cycle) to better align to the deliverable for success as opposed to not changing due to a locked down plan that leads to completing the project, albeit unsuccessfully.

Agile incorporates the ability to modify what is delivered without necessarily extending the duration, budget or scope (the three project constraints) of a project, but also does not necessarily prohibit the extension of one of these constraints.

Confusing?
Not really.

Simply put, if there is more work to complete because of our change, we could :

• extend the duration in order to get these changes incorporated in the product
• extend the cost by using additional resources to complete the change

Both of these would also extend the scope, because nothing was dropped from the scope to allow for the change.

• drop an item of equal effort to the change from the scope would allow the project to continue on track without extending budget, duration or scope

Does this sound like your corporations dream? Being able to change whatever they want when they want, even mid-project? Well, it's flexible, but not quite that simple, it requires discipline in using Agile, in fact it requires a few disciplines and for those disciplines to be understood and adhered to by a few different people too.

These are what I would like to cover over the next few months of posts...

Contents:

1. This one!
2. User Stories
3. Testing
4. High Level Prioritisation
5. Estimation (1 of 2)
6. Estimation (2 of 2)

Agile Risk Management Talk by Rowan Bunning

I attended "Agile Risk Management" presented by Rowan Bunning last night. Got to say, very well done Rowan for stepping in at the last minute. And I really mean the last minute, the scheduled presenter pulled out due to being unwell 24hrs before the event and Rowan came to the rescue. Rowan had given the same presentation recently, but still, I thought it was really good going, especially as I think we were a tough audience!

I picked up some good sound bites throughout the presentation.

1) If you want no risk, do not projects! Balance risk versus reward.
2) You can't eliminate risk, but you can manage it intelligently.
3) Impact map lays out the who, how and what of impacts were trying to have, as a mind map.
4) Creating a "safe fail" environment with iterations. Using multiple iterations, refine failed iterations making future success.
5) Risk Categories, business, social, tech, cost of schedule.
6) Which of the risk categories is most important to you?
7) Risk Discovery map. Assumptions, concerns and open questions. Used to facilitate risk discovery.

Rowan did a good interactive exercise around Risk Categories, separating the ground into sections depending on which Risk Category they thought was the most important to us. Once separated, we had to pair up and discuss why we thought our Risk Category was the most important. It was a great way to get people interacting and actively thinking and by having people only pair with other of the same view, it wasn't going to raise too many heated debates to be broken up before Rowan could continue.

PMI Sydney Talk - Risk Energetics

I attended a very interesting and inspiring talk hosted by the PMI (Project Management Institute) on 19th September 2013. I would highly recommend anyone involved in project based work to attend future PMI events.

I captured a couple of quotes that were the highlights of the talk for me below, but to get the full environmental energy and experience you'll have to attend next time!

The event was titled "Risk Energetics" with the very well presented speaker Dr David Hillson. More information can be found on Dr Hillson's website - www.risk-doctor.com.

This quote is one of the more common excuses for not dealing with risk management.
"I'm too busy to worry about things that might not happen! I've got to deal with what is happening".
It's very much an argument we have when under pressure, should we have a reactive or proactive approach? I expect we can all related to this and the difficulties associated when in different situations.

"Ability to manage risk is the difference between success and failure."
You could loosen the terms and say that the ability to manage risk is the difference between being thorough and complete AND potentially recklessly gambling or fingers crossed hoping! But certainly as a responsible project manager, even if the risk never eventuates, if you've failed to manage that risk (document, measure impact and likelyhold, plan mitigation, monitor and release), you've failed to project manage properly.

"Identify and plan response stages of risk planning require creativity."
This was very interesting about keeping energy levels up, attention focused and enthusiasm during risk planning workshops. Risk planning requires creativity and creativity requires motivated participants.

This is gold and does not really require much explanation...
"Some projects moonwalk. To moonwalk is the appearance of moving forward when actually moving backwards".

Dr Hillson promoted this book "Ruth Murray Webster - facilitating risk meetings" and ran through a few themes of resistance to risk and techniques to combat them.

Energy Sappers
- Risk process takes time and money.
- responses cost money
- it's just scare mongering
- too busy
- too late, my risks are built in
- it's just common sense

Common themes for team not engaging in risk management
- disinterest
- distraction
- disillusioned

Common solutions to promote risk management engagement
- education/explain
- focus
- demonstrate value

What can be done to Maintain levels of energy throughout the project. Renewable risk energy. Breaks, demonstrated value, education.

I loved one of the final quotes from the talk.
"The beatings will continue until the moral changes...".

Another that I was not so keen on around implementing change and change management (and I believe there was more context around it) was.
"Change the people. If that doesn't work, change the people"!

Inspiring talk as always. I look forward to the next one.

I attended a talk on Scrum last night

Sorry, very lazy, but only the Twitter highlights today. PS. It starts at the bottom!

1. Scrum presentation: Thank you Rowan. Very interesting presentation.
2. Sami Cox ‏@SamiCox21h

   Scrum presentation: Incremental approach gives greater visibility across projects to constantly assess their validity.
3. Sami Cox ‏@SamiCox21h

   Scrum presentation: Scrum Burn Down allows to see what has been done giving an actual status.
4. Sami Cox ‏@SamiCox21h

   Scrum presentation: Incremental approach allows to address release risk earlier.
5. Sami Cox ‏@SamiCox21h

   Scrum presentation: Incremental projects allow deferring of low priority features to less critical later stages.
6. Sami Cox ‏@SamiCox21h

   Scrum presentation: Incremental approach allows the evolution of vague ideas.
7. Sami Cox ‏@SamiCox21h

   Scrum presentation: Big Bang versus Incremental, ROI sooner with incremental. Quicker TTM (time to market).
8. Sami Cox ‏@SamiCox21h

   Scrum presentation: Small projects are simpler as the requirements are more set and there is greater certainty. Sprints maintain simplicity.
9. Sami Cox ‏@SamiCox21h

   Scrum presentation: The "Agile excuse", misuse of Agile eg. We're Agile so we went over budget. We're Agile so we went over schedule.
10. Sami Cox ‏@SamiCox21h

    Attending "Scrum: A framework for transforming your software project delivery capability" with speaker Rowan Bunning.