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.
Cone of uncertainty
Cone Of Uncertainty
Above is a cone of uncertainty, this image demonstrates how larger stories come with greater risk when not broken down further.
Small stories between 1-3 pt’s shouldn’t have a grey area because for the team to know that a story is so small they should have a good grasp on what is required to deliver that story. I have placed the 5pt story on the line border of having grey matter, as though 5pt stories are of a size where the team should know whats required to complete the story, I have found in practice that this is not always the case and often 5pt stories end up being more like a 6pt’ish story 
.
As the story sizes increase, so does the grey area, and the grey area is not directly relational to the ideal inner cone. Get your scrum master to keep track of estimations, the actual time taken to deliver and from this you will be able to calculate your teams multiplier for the ‘grey area’. You can then use this in your sprint planning sessions as a safety buffer.
How do you minimise the ‘grey area’? Due to the nature of large stories it is not possible to remove the grey area completely, but you can utilise methods to reduce the ‘grey’. Having well defined stories and story acceptance criteria all help reduce uncertainty around a story. Though I’d rather spend time out of a meeting, if you have a 10 pt story and your grey area multiplier suggests a 3pt buffer, but a meeting would only take 30 minutes to help add clarity to your story, do the meeting as this may reduce the 3pt buffer. Do all that you can to reduce the grey area, but accept that you will never be in a position to completely remove this grey matter.
Improving Sprint capacity planning – The safety buffer / net
If your team consistently struggles to meet their sprint commitments because they are over optimistic with their story estimations, try to create a safety buffer or safety net.
Often teams try to create a safety buffer by only filling their sprint backlog to 60-80% of their capacity, though this approach is reasonable it is not very flexible or accurate.
Instead if we measure the uncertainty around estimated story points and use this metric to determine how much of a safety buffer we need to put into place, this gives us tighter accuracy and improved burn rates.
To demonstrate this (please note this excludes any JDI, BUA, etc..);
Team A has a velocity of 20 pts per sprint, they are planning to include stories made up of ten 1pt stories and five 2 pt stories. In this case we know that for the team to know an item is a 1pt or 2pt story they must have a clear idea of what is required to get the job done and the cone of uncertainty is virtually nothing. Based on the size of the stories I would recommend either no buffer or a very, very small one.
Team B also has a velocity of 20 pts per sprint, but their stories are individually larger in size, they have a 10pt, 5pt, 3pt and two 1pt stories. As there is a element of uncertainty surrounding the 10pt, 8pt and 5pt stories, I would recommend that the team builds in a greater safety buffer than Team A as there is an increased chance of there being more unknowns that will occur whilst the team is working on these larger stories.
How do we determine what the size of a safety buffer should be based on the stories being considered for a Sprint? This would require the Scrum Master to keep track of the teams points estimations and then at the end of a sprint note how big an item of work actually was, you then can use this figure as a multiplier for future stories of the same size.
For example if when a team plans a 10pt story, they actually take 12 points worth of effort in Sprint 1, then in Sprint 2 they take 14pt’s to deliver a 10pt story you have a multiplier of 1.3 for a 10pt story. If the team selects a 10pt story in a future Sprint your safety buffer would be 3pts.
Visions and missions
In many businesses you will often hear people talking about visions and missions
Very often I've heard people refer to both visions and missions being the same, they are not.
A vision is a long term, on the horizon, place you would like to get too, you plan your missions to achieve your vision.
How does this translate into the real world? In Agile terms you could view your vision as being the end objective for your product and your missions could be your theme's, release plans, Sprint plans, etc... (depending on how you do this within your business). For example;
Vision
My vision is that my e-commerce site has more features than another
Missions
To achieve my vision I will need to;
* Build a product search area
* Build a checkout process
* etc....
You will often find that your vision will be determined by the board / senior management (in alignment to the business strategy) and the missions will planned by the Program Managers, Release Managers, Project Managers, Product Managers, etc... and the execution of these missions by all of the 'doing' staff.
Good leaders (I'll be doing a post about leadership very soon) will form a vision that is 90% achievable and 10% very difficult to achieve, but pushing boundaries, as this will challenge the teams. Leaders, to make this work, put a bonus on the team achieving that additional 10% (depending how generous you feel, and if you run with minimal marketable feature sets (MMFS) then you could use everything below the mmfs line as your bonus targets).
To avoid confusion I wouldn't have visions as part of your project planning (unless your project is on a greater timescale than your companies vision, i.e. the company has a 3 year vision and your project is going to run for 5 years), as a project should really be a mission to help you achieve your business vision.
Congratulations chaps, Norway to the UK – Walk for cancer walk for life
Congratulations chaps
Walk for Cancer, walk for life
My brother (the one in the middle), Gaz (left) and Duggie (right)
1000+ km's later the chaps completed a lap of Windsor race course after 27 days on the road.. In total they raised more than £15,000 for Cancer charities. James completed the final lap wearing our fathers shoes, who sadly lost his 7 year fight to cancer two years ago,
Agile Awards Diner UK 2011
In celebration of launching the Scrum Solutions web site, I will be presenting an award to the Best Agile Coach / Mentor in the UK.
Scrum Solutions
Driven by all things Agile
As a few of you are aware, I setup a company, Scrum Solutions, to supply Agile specific stationary, software (inc. iOS and Android) and consultancy.
Though we have already taken a number of orders, it brings me great pleasure in announcing our go live date of our web site will be the 11th July, www.scrumsolutions.co.uk. This will give our customers greater flexibility to explore and order our extensive range of products as well as review purchase order history.
To celebrate the arrival of the web site, I am pleased to announce that Scrum Solutions is a sponsor of the Agile Diner UK 2011 and I will be presenting the award for the Best Agile Coach / Mentor at the event.
The ‘Agile Pirate’
As many of those who know me know, I don't like soap box preachers, those who preach but incapable of putting it into practice.
I've been working @ GE now for just over 3 months and during that time I've had the pleasure of working with Simon Cromarty, aka 'The Agile Pirate'. A person who can demonstrate what he preaches and deliver success.
Simon is the best Agile guru in the UK. Simon is genuinely too modest to even contemplate that idea, but pound for pound Simon would be Manny Pacquiao of the Agile world. He is a great advocate of everything Agile.
Simon has helped me to grow, improve and galvanize my views around everything Agile. I wish him the best of luck, Redgate have done a great job of landing Simon, and I look forwarded to working with you again one day.
Sharepoint and bad processes – BA’s first
One of my all time favorite frameworks is Sharepoint.
Sharepoint helps me to bring 'togetherness' to teams I'm working with, it helps them to communicate and collaborate with their fellow colleagues no matter where they are in the world.
Not everyone shares the same view as I. It got me thinking, 'Why do I see this as an amazing tool and others don't?' After the cogs had turned a few times I and talking to my teacher friend, the answer hit me. Sharepoint is a great enabler if your business processes / workflow are good, but if the business processes / workflow you feed into Sharepoint is bad or poorly defined then Sharepoint will only further highlight the your process / workflow problems.
When implementing Sharepoint, do it correctly, its not about techies, its about a team of BA's to analyse the existing processes / workflow and improve these before feeding them into Sharepoint.
BA's first techies second.