A Practical Guide: Story Points-Based Estimation

Glad to see that my article made it +Scrum Alliance

http://www.scrumalliance.org/community/articles/2014/january/a-practical-guide-story-points-based-estimation

The road to Continuous Delivery

Continuous Delivery it's a software development practice where you make sure that your application is ready to be deployed to production at any time. You’re not only making sure that when a developer commits a change is, it is correctly integrated by building and unit testing your application (Continuous Integration). You’re also making sure that your application is always ready to be deployed by running automated and/or acceptance tests on it and testing the release process itself.

Practicing Continuous Delivery gives you several advantages:

+The time from idea to deployment to production (cycle time), is shortened.

+By shipping the product early you are encouraging early feedback. The faster you get your software to your end-user, the faster you get feedback.

+You’re always ready to deploy to production. You do not have to spend time making and testing a release.

+Because you’ve already tested the release process itself, deploying to production is simple and error-free.

+You are getting ahead of the competition and making your release process a business advantage.

How to implement ?

• Ensure both your developers and system administrators are responsible for deployment. Traditionally, the system administrator is responsible for deploying to production. By making your developers responsible too for deployment you are encouraging a culture of collaboration (DevOps) and lowers the chance of errors due to miscommunication.
• Find out what your release process looks like, make it reliable and repeatable and automate as much as possible. Make every step of the process reliable and repeatable. When your steps are reliable and repeatable, then they can also be automated. As our goal is to automate each step.
• Setup one single way of deployment to an environment. Make sure that you define a single way to deploy a release to an environment, whether is it the test environment or to production. If you do this, then you’re also testing your deployment process itself.
• Test on a production-like environment. If you test on a different environment than your production environment, then there is a risk that your deployment to production doesn’t work or worse: your end-users experience runtime problems due to different software versions of third-party software and libraries.
• Quality first Keeping your application deployable should get higher priority than adding new features. If an error in your release process occurs, fix it as soon as possible.

Where do I start ?

It takes effort to fully practice Continuous Delivery. But you may start slowly by:

• Let your developers and system administrators work together on deploying your application.
• Visualize your release process.
• Make steps of your release process reliable and repeatable

Get Real

An introduction to Smaller, faster, better way to build software. Well then, it's time to skip all the unnecessary stuff and focus on build the real thing. Some of it I have listed here which you can stop doing and build the real thing.

Let's get rid of >>>>

Timelines that take months or even years

Pie-in-the-sky functional specs

Scalability debates

Interminable staff meetings

Useless paperwork E.g. charts, graphs, boxes, arrows, schematics etc.

The “need” to hire dozens of employees

Meaningless version numbers

Pristine roadmaps that predict the perfect future

Endless preference options

Outsourced support

Unrealistic user testing

Top-down hierarchy

Let me know if above these helped you anyway ever to build the real thing.

***Then how to build the real thing!

Do you remember Agile Manifesto(s) ? Read more

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer Collaboration over contract negotiation

• Responding to change over following a plan

Interestingly if you follow what I have listed above and get rid of the ones I mentioned, you will see how quickly you be adapting to these new changes and start building the real thing early before your competitor builds it :-) Sounds easy ! Well then it's time to Be Agile and follow Scrum !

With the advent of Object Oriented Software development methods it became easy to break large software projects into very small components and therefore able to take advantage of the building incrementally during Sprint, build the MOST important feature first. Since each sprint outcome is working element of the product this ensures rapid feedback and adjustment to the changing needs to the marketplaces.

Let me provide you an quick introduction to Scrum Vocabulary (Note: this is probably the smallest introduction I have ever written :-) So feel free to read other relevant ones you will find in my blog)

What is it ? 

Scrum provides a language for this common sense way of organizing, performing, and managing work.

Product Backlog:

All work to be performed in the foreseeable future, both well-defined and requiring further definition.

Sprint:

A period of 30 days or less where a set of work will be performed to create a deliverable.

Sprint Backlog:

That work that is well enough defined that it can be worked on with relatively little change over a period of 30 days or less and will result in a tangible, incremental deliverable.

Scrum:

A daily meeting at which progress and impediments to progress is reviewed.

Do you agree with me with the benefits of Getting Real ?

Getting Real delivers better results because it forces you to deal with the actual problems you’re trying to solve instead of your ideas about those problems. It forces you to deal with reality.

Getting Real foregoes functional specs and other transitory documentation in favor of building real screens. A functional spec is make-believe, an illusion of agreement, while an actual web page is reality. That’s what your customers (whether internal or external) are going to see and use. That’s what matters. Getting Real gets you there faster. That means you’re making software decisions based on the real thing instead of abstract notions.

Finally, Getting Real is an approach ideally suited to web or mobile-based software. The old school model of shipping software in a box and then waiting a year or two to deliver an update is fading away. Unlike installed software, web apps can constantly evolve on a day-to-day basis. So far it I have taken advantage of this approach of Getting Real. Are you thinking ? I think it's worth a try! 

"Agile"

I know you may have read many articles and probably tried picturing the definition of "Agile". But if you are confused by complicated terms then this post may help you. I have tried to put it in simpler terms.

Let's go over what is Agile ?

Agile is a philosophy that uses organizational models based on people, collaboration and shared values. Agile promotes three core values : trust, transparency and collaboration.

How it works!

Agile uses rolling wave planning; iterative and incremental delivery; rapid and flexible response to change; and open communication between teams, stakeholders and customers. There are many agile methodologies that adhere to these tenets, such as Scrum, XP, Lean and Test-driven Development (TDD), etc.

How it helps!

Agile principles and practices are topics of growing importance in project management and used by most successful companies. Project management practitioners, software development teams can use agile principles and practices to successfully manage change,improve communication, reduce cost, increase efficiency and demonstrate value to customers and stakeholders.

Let's go over few core agile principles and practices (tried putting together in simpler terms)

• Early, measurable return on investment through defined, iterative delivery of product increments.
• High visibility of project progress allows early identification and resolution or monitoring of problems.
• Continuous involvement of the customer throughout the product development cycle.
• Empowerment of the business owner to make decisions needed to meet goals.
• Adaptation to changing business needs, giving more influence over requirement changes.
• Reduce product and process waste.

Hopefully this helps you understanding the principles and practices agile proposes. I will post about Agile Manifesto on my next post.

How to write User Story ?

Over the years I have worked with quite a few Product Owners and also I have played that role myself but often I have seen people having very minimal knowledge about writing good user story and that does impact development. So this post is all about it how to write good user story!

Before I get into it I prefer to put an example of how an user story should be written:

If you notice this example meets the following high level definition of what a Product Owner should write:

• Provides a simple medium for
• Gathering basic information about stories
• Recording high-level requirements
• Developing work estimates
• Defining acceptance tests [Normally been written in the back of 4"X6" card, however if you are using any online tool most of them provide acceptance criteria block.

• Acts as agreements between customers and team members to discuss detail requirements during an iteration

However, here I have put together the detail definition we should capture in user story and here the participants are Team and Product Owner who needs to write this together:

• Story identifier and name
• Story description: A sentence or two that describes the feature in customer terms
• Story type (C = customer domain, T = technology domain) [E.g. customer domain would be something which comes from customer thus this is nothing but features whereas something would be called as technology domain which comes from the team say refactor certain area of the code or support they need to get something done etc.]
• Estimated work effort: The estimated work effort needed to deliver the story, including time for requirements gathering, design, coding, testing and documentation.
• Estimated Value Points
• Requirements uncertainty (erratic, fluctuating, routine, stable): An "exploration factor" for a specific story
• Story dependencies: Dependencies that could influence implementation sequencing
• Acceptance tests: Criteria the customer team will use to accept or reject the story.