23 Oct 2014

From semi-finished to finished user stories



One of the cornerstones of being agile is to deliver done features by the end of short sprints. Done as in potentially shippable. Done as in implemented, tested, documented and possible to deploy into production.

 

This is a typical semi-finished user story

Common arguments why user stories are left semi-finished:

 

 

 
  • we are not used to copmleting them (...yet)
  • we think it is unfair not to take credit for partly done work (it looks worse than it is, and we are afraid that management does not see this bigger picture)
  • we do not see the point in delivering smaller parts that is truly done
  • I think I am more effective if I can focus (all my time) on the one type of task that I am best at (rather than optimizing for the team and product delivery)
  • we are different than other product development teams –this might be a good idea in other teams or organizations, but not here
  • we are not prepared for the visibility this will provide (goes for both management and team members)




Ripple effects of done

Why is it so important to deliver finished user stories?

Focus on delivering something that is finished each sprints will provide you great benefits:



1: Deliver real value -early. Get the great features out to the customer, not storing them on the shelf.
2: True visibility of progress, and make any unresolved issues visible. Handling unresolved issues before moving on to new stories will reduce risk for the company/product delivery, and create visibility of the reality. This is important for any team :)
3: Ability to deliver the true minimal viable product. Help each individual on the team to participate in dividing the user stories into small enough pieces. This in turn will help the company to deliver the true minimal viable product, making the product development more flexible: you will be able to deliver a first release, then learn, then add more features, learn more and so on. –A great place to be!
4: Pull together as a team. The team will become great at collaborating to finish a user story and helping each other out on that rather than only optimize for the individual preferences of tasks to solve. This can seam harsh in theory, but in reality, the reward is intrinsic motivation triggered by being a part of something greater than the, it gives a sense of purpose. (of course the teams needs to be put together with interesting tasks for everyone most of the time, and by people that are motivated by and skilled at similar and different tasks) 

5: Trust. When you deliver finished stuff, the rest of the organisation trusts you. Then you get the freedom to make smart choices work a way that make sense. 
 

How to get there?

In Scrum you do get some help on visibility of how good you are on finish user stories:
  • You do not review any partly done user stories (show only finished stuff)
  • You do not take credit in any sense of user stories that are partly done (it can be visualized on a burn down chart)
Does it seem harsh? Maybe. Still I think the reasoning behind focus on completing user stories makes it worth while, I can not see how anyone can be agile and still leave unfinished work. 
  • Understand the reasoning behind by reading up on the topic, talk to others and join the agile community. Then you need to work the knowledge into your culture. Inspire, educate and engage. 
  • I reccomend any team to give it a whole harted try for 6 months
  •  I would also allow time to make the necessary adjustments:  
 Most certainly, there are many reasons both technically and human that needs to be addressed in order to get to a place of making user stories that is done and truly done.

You can do it!


Further reading:

2 comments:

  1. Excellent points. The benefits of getting a well-oiled scrum machine rolling far outweigh any perceived difficulties and culture changes in adoption of agile principles.

    ReplyDelete
  2. Thank you for your comment, Steve!

    ReplyDelete