Scrum with pen & paper
A friend of mine recently asked me if I'd know any good freeware tools for use with Scrum. Well, I told him, I don't have any first hand experience with freeware Scrum tools but there certainly are a few.
However in the case that you're just starting with Scrum I would argue that you might be better off without tools. All tools force you into some kind of process that works for somebody else, but might not be optimal for you.
So instead of jumping to a fancy tool that comes with all the bells and whistles instantly, I'd recommend starting as low-tech as possible, learn the basics and discover your individual needs. After that you are enabled to get the Scrum tool that does exactly what you need it to do.
How do you start low-tech? Use pen and paper.
Estimation techniques compared
I was inspired to write this article by several threads in forums covering agile methodologies. The basic discussion was whether to estimate based on Story Points or time. To me - and most people participating in those discussions - there is no silver bullet and you will have to find out what works best for you yourself. In this article I'd like to muse about the various estimation techniques that I'm familiar with as well as the pros and cons that I ran into with each of them.
I will compare PERT and COCOMO, both being traditional techniques with a long history and Planning Poker, probably the most prevalent agile estimation technique.
All techniques have their pros and cons and it will be up to you to determine which technique will work best in your environment.
My comparison is purely based on experience, which is broader for PERT and more narrow for COCOMO and to some extend Planning Poker. Your mileage may vary. This article does not intend to be the definite guide on estimation techniques.
That being said, let's start shall we?
Ken Schwaber’s “Confusion about Scrum”
On December 31st 2009 Ken Schwaber posted his article "Confusion about Scrum" in the Yahoo ScrumDevelopment Newsgroup.
He states that
There are now two definitions of Scrum. One is maintained and sustained by Jeff Sutherland and myself at www.scrum.org. Another is an old copy that is posted at www.scrumalliance.org, by the ScrumAlliance.
His article continues mentioning what sounds like the start of a copyright dispute over the Chinese version of the Scrum Guide (English version) which in its original form is written and maintained by Ken Schwaber and Jeff Sutherland. Apparently now the ScrumAlliance claims ownership to the Chinese translation of the Scrum Guide (again the English version). As Ken points out
Any of you familiar with copyright law know that a derivative of the original is still owned by the original copyright holder.
Ken Schwaber recommends
that you refer to the Scrum Guide created and sustained by
the authors of Scrum, Jeff and myself.
This is serious news.
Attempting Scrum in a SDLC environment, pt. 2
In the first part of this article series, I covered the aspects of the real life office environment. This included the lack of physical space for pinboards etc. Go check it out.
In this second part I will focus more on the virtual environment, the tools typically used by a company following the traditional waterfall approach / SDLC and how you might still be able to use these tools for Scrum.
Bug tracking system
Let me start with the bug tracking system. Most likely your organization will have one of those. Typically issues can be categorized, prioritized and assigned to a person as well as tagged or grouped into releases. To make this tool work for you in a more agile way you could create a couple of additional categories and put everything (!) into that system: Don't put only issues into it. Also add things like feature requests, enhancements, documentation, testing and refactoring tasks. I'm sure you can come up with more with a bit of thinking. Just be careful not to make this more complicated than required... 
Well, that looks pretty much like a product backlog to me. You can do a printout of the overview and pin that to the board for better clarity. Stick it to the window with Scotch Tape if you don't have a pin board. In any case you should make this virtual backlog physical, otherwise the transparency will suffer. Only with a physical product backlog the team will have a clear idea about the big picture.
The overhead to maintain that printout would be minimal. You effectively avoid having two independent lists (in my experience always a recipe for disaster) and your not-so-agile management will probably be pleasantly surprised by the transparency you introduce.
Welcome!
Hey! I'm glad you could make it.
Here I keep posting my latest experiences, but also technical oddities and curiosities as well as random thoughts and ramblings.
All of it will be related to the IT industry and me in it.
My thought cloud
Entries by topic
- Agile (14)
- Commerce (1)
- Events (3)
- General (8)
- Management (7)
- PHP (3)
- Social Web (2)
- Test Automation (5)
Events Calendar
Pages
Other places to find me
Xing Profile