Carl Bruiners
I specialise in all things Agile (XP, Kanban, Lean), in particular Scrum. I have a passion for taking on 'problem' projects / teams and turning them into a sucess as well as promoting automated test driven practices.
More 
I am an enthusiastic, dedicated and accomplished Systems / application Architect, Project / Product Manager, Development Manager and Application Developer who thrives on delivering first class products.
My background is that of a developer who became a product / project manager and the head of application development. I am a certified SCRUM Master and have solid knowledge of PRINCE2.
I Work well on own initiative and can demonstrate high levels of motivation and organisation required to meet targets and deadlines. I have excellent interpersonal skills and communicate well at all levels.
Details
Contact Carl Bruiners
Carl Bruiners Twitter
Carl Bruiners LinkedIn
Carl Bruiners Scrum Alliance
Tags
Recent Posts
- Agile Awards UK 2012 – Nominated…
- Sovereign teams
- Mr Ching keynote speaker at Scrum Gathering Atlanta 2012
- Is limiting what my partner can buy a bad thing?
- Dubai
- Heston and Ramsey got it so wrong…. and why Scrum could help in the kitchen
- Mr Eddie Thomas
- Big update coming for the really simple Agile tool
- A really simple Agile tool – DB structure
- The really simple Agile tool – update
- Book review: Kanban by David Anderson
- Introducing the really simple Agile tool
- Agile Edge presentation
- Agile test curve
- Personal online security
- Over the GUI test automation, Excel and a little VBA
- Identifying an Epic using apple strudel
- Reap the QA rewards by reducing defects
- Development stuff
- Difference between UI and UX
Categories
- .NET (5)
- Agile (29)
- ASP.NET (2)
- Book reviews (1)
- c# (2)
- Continuous Delivery (2)
- Continuous Integration (1)
- CSS (1)
- Development (2)
- ITIL (1)
- JavaScript (1)
- JQuery (1)
- JS (3)
- Kanban (12)
- Lean (11)
- Misc Stuff (21)
- Product Management (2)
- Project Manageent (8)
- QA (2)
- SCRUM (34)
- Scrum Solutions (3)
- Security (1)
- Sharepoint (2)
- Silverlight (1)
- Technology (8)
- Test Automation (3)
- the really simple Agile tool (2)
- Travels (1)
- Uncategorized (2)
- VB (3)
- XP (10)
Blogroll
- Clarke Ching
- Karine Bosch
- Mike Cohn
- Peter Drayton
- Robert Lindström
- Scott Gu
- Simon Cromarty
- Stu Nicholls
- Tobias Zimmergren's
Archives
- April 2012 (8)
- March 2012 (4)
- February 2012 (2)
- January 2012 (7)
- December 2011 (3)
- October 2011 (3)
- August 2011 (3)
- July 2011 (3)
- June 2011 (9)
- April 2011 (9)
- March 2011 (3)
- December 2010 (1)
- November 2010 (1)
- October 2010 (10)
- September 2010 (1)
- August 2010 (3)
- July 2010 (3)
- February 2010 (2)
- December 2009 (1)
- November 2009 (3)
- October 2009 (6)
a really simple Agile tool
Powered By UserVoice.
The anatomy of a good story
I often get asked what a 'good Story' looks like. Creating a great Story isn't as difficult as people think, nor does it require an understanding of the dark arts.
A good Story should include as much descriptive text to describe the story as needed, though you should resist the need to write down too much detail (http://carlbruiners.com/2011/06/amber-is-heathly-green-means-youve-over-cooked-it-and-red-means-we-havent-got-a-clue/) in favour of writing a concise paragraph or two. To help support this concise paragraph (or two) break it up into a bullet point list which acts as your Acceptance Criteria. Also remember to keep in mind I.N.V.E.S.T (Independent, Negotiable, Valuable, Estimable, Small and Testable).
The only difference between a User Story and a Story is that a User Story must written in business english; i.e something that most people wil be able to understand if they even have a small amount of knowledge about the product. A User Story is from perspective of the User (hence its obvious naming).
A vanilla Story though should start off by identifying the requesting role type;
- As a developer...
- As a tester...
- As a architect...
- As a documenter...
And though you should ideally keep the text as readable as possible, you could add in detail such as a method name or a class name for example. Remember that you should always include Acceptance Criteria for both Story types.
How do you qualify your stories? For User Stories get a BA to read the story, ask the Product Manager to skim over the backlog and always ask the team to review your stories (normally when being chosen for a Release Backlog, don't waste time defining stories that may never get played). As a double check (when the team Scrum Master) I often read the User Stories and if I can understand that unit of work then its a good indication that the story is defined clearly enough.
Using User Stories / Stories and Tasks to feed traditional document centric models
Project documentation is often an area I see companies struggling with when it comes to Scrum. A simple way to remove this major impediment is to use your user stories to drive your more traditional functional specification and for your techie stories (not user stories) / tasks to be used for your technical documentation. For project imitation I find it best if the product manager can supply;
- High level brief - No more than 1-3 paragraphs
- High level goals - 1 paragraph with bullet points per feature
- Acceptance criteria - based on the high level goals, often a high level goal will generate multiple acceptance criteria. A validation rule, if you have a high level goal with no acceptance criteria, then it is not deliverable, so either remove the high level goal or change it so that it can have acceptance criteria.
There is often a need to document every aspect of what is to be built, but the reality is we know that often adopting this approach means that what we expected at the beginning of a project is not what is delivered. Heavy upfront documentation will not promote lateral thinking, and allow either the business or supplier to deliver the most suitable product for market.
Difference between a user story and a story
A user story defines the requirements of the business and is written by the PM along with a BA (if available / possibly the same person), the user story is then broken down into individual stories that can be delivered against, which in turn is broken down into individual tasks.
Sounds simple, but in practice it is often not achieved. If you don’t break down User Stories you’re always working against Epic scale stories. It is critical to break down user stories into multiple stories so that each story is deliverable within an iteration (or if using Kanban ensures it can fit into the swim lanes).
It is important to break down stories into tasks so that you have a clear vision of what needs to be achieved to deliver the story. Having tasks also allows us to understand during an iteration how much time is remaining. Story estimations are finger in the air stuff, in particular if you are using relative points as your measurement, task hour / day measurements helps us to understand the actual remaining time against the original story estimation. Long term this will help improve your team’s ability to better estimate both user stories and stories.
On a side note, even though acceptance criteria is only a must have for user stories and stories, I also encourage teams to have acceptance against a task. Doing this increases QA throughout the whole of the process.