“The minimum viable product is that product which has just those features (and no more) that allows you to ship a product that resonates with early adoptors; some of whom will pay you money or give you feedback” – Eric Ries
When is something done? What does DONE mean?
In the teams of software development, here is a definition that can apply to this process:
Definition of Done
The meaning of done is an agreed upon list of the activities necessary to get product increment to a production ready state.
- Development completed
- Passed code and peer review (Pull Request in BitBucket)
- All Technical documentation is created and stored in the source repository
- Sanity check to confirm technical debt is identified and logged in the tech debt register identified and logged/recorded?
- Testing has been completed and no issues logged against acceptance tests.
- Deployed and tested against the acceptance criteria in a valid environment
- All non-functional requirements have been met
- Regression test packs updated
- Update tickets, including documentation, annotation and outcomes
- Product owner/Business Designer has signed off the work.
- Release to Production
These are the necessary steps that apply to the development process where every you work
Procedure & Rules
An important element of Scrum is to estimate the complexity of features in the product backlog. For the estimation process, we use a simplified Fibonacci sequence: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100.
Continue reading Story pointing
Your software team has a process that use to complete work. Normalizing that process–i.e., establishing it as a workflow–makes it structured and repeatable, which, in turn, makes it scalable. With your development team, you can take an iterative approach to workflow management because it helps you meet your goals faster and exemplifies your team culture.
Continue reading Development Process Flow
Microsoft have just published this great eBook which helps web developers cut right to the code scripting of environments to make all the firewall ports and get code done quickly by providing an overview of key services in the cloud, what services to use based on your needs, step by step guidance, sample code, sample applications, and a free account to get started.
Here is a list of areas it covers
- When to Use It
- Moving an Existing ASP.NET Website to App Service
- Identity Management
- Scaling your Web App
- Caching for Performance
- Better Customer Experience with a CDN
- Detect Failures Faster
- Building a New Website on Azure App Service
Scrum and Kanban are two terms that are often (incorrectly) used interchangeably or thought to be two sides of the same coin. In reality, there are significant differences between these two Agile methodologies. Understanding these differences is key to choosing the path that will work best for your environment. In a nutshell, what is Scrum? Without getting too detailed, Scrum is a tool used to organise work into small, manageable pieces that can be completed by a cross-functional team within a prescribed time period (called a sprint, generally 2-4 weeks long). To plan, organise, administer, and optimise this process, Scrum relies on at least three prescribed roles: the Product Owner (responsible for initial planning, prioritising, and communication with the rest of the company), the Scrum Master (responsible for overseeing the process during each sprint), and the Team Members (responsible to carry out the purpose of each sprint, such as producing software code.) Another common tool used by scrum teams is the Scrum Board – a visual representation of the work flow, broken down into manageable chunks called “stories”, with each story moved along the board from the “backlog” (the to-do list), into work-in-progress (WIP), and on to completion.
What is Kanban?
Again, scratching the surface, Kanban is also a tool used to organise work for the sake of efficiency. Like Scrum, Kanban encourages work to be broken down into manageable chunks and uses a Kanban Board (very similar to the Scrum Board) to visualise that work as it progresses through the work flow. Where Scrum limits the amount of time allowed to accomplish a particular amount of work (by means of sprints), Kanban limits the amount of work allowed in any one condition (only so many tasks can be ongoing, only so many can be on the to-do list.)
How are Scum and Kanban the same?
Both Scrum and Kanban allow for large and complex tasks to be broken down and completed efficiently. Both place a high value on continual improvement, optimisation of the work and the process. And both share the very similar focus on a highly visible work flow that keeps all team members in the loop on WIP and what’s to come.
How are Scrum and Kanban different?
As alluded to above, there are a number of differences in both the philosophy behind and the practical application of Scrum and Kanban. While the individual differences are many, they can be grouped into the following three buckets:
Scrum processes place heavy emphasis on schedule. The scrum team is provided with a prioritised list of story points that need to be completed to deliver a shippable product. The team must decide how many of the points they feel can be completed within one sprint. Anything outside the scope they commit to must wait for the next sprint. Optimally, an efficient scrum team will quickly learn their capabilities over the course of several sprints and their estimates will improve and be optimised as time goes on. Then, every two weeks (or however long their sprint is) the team produces a shippable product, carries out a retrospective to discuss optimising the process, and moves into the next sprint. This iterative process is designed to allow for accurate estimations of work flow and effective management of multiple projects. On a Kanban team, there are no required time boxes or iterations. While the Kanban method is iterative in nature, the continual improvement is expected to occur in an evolutionary fashion as work is continually completed. The limitations placed on various conditions in the work flow will be regulated early in a team’s (or organisation’s) use of Kanban until an optimal set of limits is arrived at to keep the flow steady and efficient.
Roles and Responsibilities
On scrum teams, there are at least three roles that must be assigned in order to effectively process the work: the Product Owner, Scrum Master, and Team Members. Each role has its own set of responsibilities, and they must work together to achieve an orderly and efficient balance. The scrum team itself also must be cross-functional, which is to say that one team must have all the resources necessary to complete the entire sprint’s work. Under Kanban, no set roles are prescribed. Practically speaking, it makes sense for someone to serve as a project manager or supervisor, especially for larger more complex Kanban projects, but the roles should theoretically evolve with the needs of the project and the organisation. A Kanban team is not required to be cross-functional since the Kanban work flow is intended to be used by any and all teams involved in the project. Therefore, a team of specialists and a separate team of generalists may be working on different aspects of the same Kanban project from the same board, and that’s okay.
While very similar, the Scrum Board and Kanban Board are different animals. On a Scrum board, the columns are labelled to reflect periods in the work flow beginning with the sprint backlog and ending with whatever fulfils the team’s definition of done. All the stories added to the board at the beginning of each sprint should be found in the final column at the end of that sprint or the sprint was unsuccessful. After the sprint retrospective, the board is cleared and prepped for the next sprint. On a Kanban board, the columns are likewise labelled to show work flow states, but with one vital difference: they also publish the maximum number of stories allowed in each column at any one time. This enforces the team-determined limitations Kanban prescribes for each condition. Since each column has a limited number of allowed stories and there are no required time boxes (such as sprint length), there is no reason to reset the Kanban board as work progresses. It will continue to flow for as long as the project continues, with new stories being added as the need arises, and completed stories being re-evaluated should it be necessary.
Which is better for your needs?
There’s really no way to answer that question for you in this article. Both Scrum and Kanban are powerful, proven process tools that can vastly improve your project management. The best option is to become familiar with both of them and experiment with various aspects of both in your production environment. Creating a hybrid of both is perfectly acceptable if that works best for you. For more information about Scrum and Kanban, take a peek inside this webinar and learn how to incorporate these approaches into your overall strategy.
There are many ways of managing a Scrum Sprint, but I always look for the easy ways, I came across Deborah Hartmann, spreadsheet which I have found very useful and easy to get along with. Once you understand the processes of Scrum and what is required the spreadsheet speak a thousand words.