• Quick Overview of Acceptance Criteria

    I think the terms acceptance criteria, acceptance tests etc have caused a lot of confusion, in some environments they are separate, in others they are blurred. I always strive to ensure that the acceptance criteria for a theme, epic or story is defined. This acceptance criteria is the outcome and agreement with stakeholders, customers and

    Read More >>

  • Agile Restrospectives

    Agile retrospectives are all about getting the team to self-reflect, provide unified feedback and from that feedback take actions to self-improve. I saw the feedback model for individuals and thought that it could easily be adapted for retrospectives and seems to offer much more than a simple what went bad what went wrong practice. Retrospective

    Read More >>

I have seen many questions, debates and statements made about the ‘Business Analyst Role’ in an agile environment. I am hoping that this post will help answer, clarify or stimulate your own alternative thoughts and views. I have just dumped my thoughts so excuse the format and lack of structure. Over the years I feel

I had a thought today and I looked back long ago to when I was not using agile and how my project managers reported. In most organisations we have the so called ‘traffic light’ status report. I spent some time reflecting on experiences and it is very easy to see how agile really does take

I have written this article in the hope that it will help people avoid experiencing the mess that I have seen companies get themselves into on enterprise projects. I say enterprise projects here and this refers to your large program / project corporate environment. On small projects, other environments or in a ‘heaven’ scenario where

Agile Resistance

Posted by: on February 2nd, 2012

I feel that as agilists we forget how agile can impact people. Agile is trying to undo decades of behaviour and practices, it is a massive change for some. Agile does not fail it is people who fail. Every failure I have been in has resulted in failure only because of non acceptance or where

Why agile works

Posted by: on July 5th, 2011

I tried to visualise why agile works in a one pager, the intent is to show the short feedback cycles and the increased risk exposure over time. WhyAgileWorks.PDF

Waterfall Stop Sign

Posted by: on April 4th, 2011

Tony, a fellow agilist was traveling the other day to a client and came upon the following , it was too hard to resist, I hope it can be taken with a pinch of salt by the heavyweight traditionalists, a bit of friendly banter is a good thing as long as the different delivery models

Has man forgotting the need to experiment so that he can learn? as each week passes I am realising that he has ! perhaps this is the time for universities and colleges to create a dedicated subject for an entire semester on “Learning through experimentation.” In my current agile project (which is well into implementation)

Scrum Themes

Posted by: on November 25th, 2010

SYNOPSIS There is a lot of confusion amongst scrum practitioners on what a theme is.I have seen articles that talk about the theme for a sprint (I see a sprint theme as a goal.) I cannot say that this is incorrect as it depends on the perception of the individual. This article provides you with

A SMART way for setting goals…

Posted by: on February 21st, 2010

What is SMART? SMART is a simple technique that helps you set goals effectively, be it product, organisational, project or for sprints. This is an effective tool to include in your Scrum techniques. What does SMART stand for? Specific Measurable Agreed Realistic Timebound SPECIFIC When setting our goals we do not want them to be

Small things to make the day count…

Posted by: on October 23rd, 2009

Recently I was working in an agile environment where everyday one of the employees would use the local newspaper that contained a general knowledge quiz. Everyone in the group would get together for 5 minutes while he read out questions and everyone would attempt to answer. It was such a small thing but it became

I once observed a practice where story cards were only estimated based on the development effort. This is problematic as it has one specific focus and not looking at the total work that needs to be completed for a story to be moved into done. Product development is not just about writing code.

THE 5 WHY’s FOR ROOT CAUSE ANALYSIS:

Posted by: on October 24th, 2008

A very simple technique to find out the root cause of a problem is to use the 5 Why’s. The number 5 is just a general guideline and sometimes it may take a lot more or a lot less “why” questions to arrive at the root cause for a given problem. The beauty of this

SCRUM POEM

Posted by: on July 24th, 2008

Not sure if anyone has ever written a scrum poem so gave it a crack ….. It is a thing called scrum and this is how it is done. We talk and discuss Then we create a product backlog without fuss A backlog has many items , they call each one a story and its

USING T-SHIRT SIZES FOR USER STORY ESTIMATION

Posted by: on March 14th, 2008

There are a number of story point scales used for estimating user stories on the product backlog. An effective scale to use for your estimation is T-Shirt sizes. T-SHIRT SIZES Size                                    Points to Allocate XS (Extra Small)                   1 S  (small)                                2 M  (medium)                         4 L  (Large)                               8 XL (extra large)                   16 XXL(extra extra large)      

Why are fixed length sprints (iterations or timeboxes) of the same duration important? why should these sprints not exceed a 4 week timebox? WHY 4 WEEKS? Scrum recommends that iterations do not exceed 4 weeks. I have heard of some implementations using 6 weeks. I stick with durations of 4 weeks or less. 4 weeks