This post isn’t really news – the agile manifesto and agile principles have been put down on paper in 2001. However I wanted to post this here, so I can look it up anytime! :)
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
- Customer satisfaction by early and continuous delivery of valuable software
- Welcome changing requirements, even in late development
- Working software is delivered frequently (weeks rather than months)
- Close, daily cooperation between business people and developers
- Projects are built around motivated individuals, who should be trusted
- Face-to-face conversation is the best form of communication (co-location)
- Working software is the principal measure of progress
- Sustainable development, able to maintain a constant pace
- Continuous attention to technical excellence and good design
- Simplicity—the art of maximising the amount of work not done—is essential
- Best architectures, requirements, and designs emerge from self-organising teams
- Regularly, the team reflects on how to become more effective, and adjusts accordingly
The definition of ready and definition of done can potentially be a matter of discussion between product owners, developers, quality engineers, designers and stakeholders – to have a guideline, I think the following suggestions can be quite helpful for this topic:
Definition of ready
- User story
- Description of GUI with mockups & designs added
- Description of story is consistent and clear
- Acceptance criteria completed
- Dependencies with third-party applications clarified (e.g. CRM or finance systems, DWH, etc.)
Definition of done
- Acceptance criteria fulfilled
- Deployed and tested on test environment
- Test cases documented & executed
- Handover to server engineers done
After over eight years of software product management in different industries (web portals, banking, payment, etc.), I worked with different software development methodologies – from waterfall approaches to agile models such as Scrum or Kanban. In my opinion, every approach has its right to exist and might be the best possible solution in a given situation, depending on the type of project, culture, requirements, degree of maturity of all involved people, etc. I really love working with Scrum or Kanban and recently wanted to come up with a summary of all differences between these two methodologies, since lines seem a bit blurred here in my opinion. Here’s what I come up with:
- Artifacts: Scrum board, backlog, different types of requirement hierarchies (e.g. theme, epic, story, task), burn-down chart, velocity, etc. in Scrum vs. only a board in Kanban.
- Iterations: Yes (sprints) for Scrum vs. no (a continuous flow) for Kanban.
- Estimations: Yes for Scrum vs. no (items of similar sizes) for Kanban.
- Changes: To be defined, groomed and estimated for the next sprint in Scrum vs. added to the board as needed in Kanban.
- Roles: Product Owner, Scrum Master and Team in Scrum vs. Team and other needed roles in Kanban.
- Teams: Cross-functional in Scrum against teams which can be specialized in Kanban.
- Ceremonies: Sprint planning, daily stand-up, sprint review and sprint retrospective in Scrum vs. daily stand-up, regular reviews and retrospectives on set dates and continuous planning in Kanban.
I found this website today, which seems like a really useful resource for many different kinds of agile development topics (implementing agile methodology in a company as well as agile leadership, estimating, planning, project management, testing, writing user stories and much more) – check it out here: http://www.allaboutagile.com/
Since last week, we have a new scrum master in our company. Last week, she had her certified scrum master course held by Boris Gloger (I also took the course in 2008 and really liked it, I would recommend Boris Glogers courses to anybody who wants to know more about scrum). Enthusiastically, she came back in the office and compared the theoretical lessons of her scrum master course to how we do it in the company. As she already encountered that estimations are not always easy and we regularly get quite high estimates from our developers, she discussed this topic with other participants and also read her first blog entries on how to make estimates more precisely. At the moment, the highest estimate we accept has the value of 40 story points, but some of her discussion partners said that they only accepted 8 or even 5 story points as the highest value – otherwise, the story is still not precise enough and needs to be split into smaller ones. I totally understand that smaller stories can have a positive effect on the planning security, but I’m just not quite sure if this works for us too or if the discussion about how to split a story into various smaller ones will take lots of time! I guess, I’ll have to let myself be suprised. I’m going to give you an update in another blog entry as soon as I found out more!
You use scrum to manage your projects? If so, this might be interesting for you: On infoq.com you can download the current version of Boris Glogers Scrum Checklist. I attended his Certified Scrum Master and his Certified Product Owner courses which got me into agile software development http://www.infoq.com/minibooks/scrum-checklists