You might have heard about XP Day – an international conference about Extreme Programming and Agile processes. We’re very happy that Apiumhub’s team in Vietnam had the chance to attend this great and helpful event; XP Day Vietnam. We can definitely say that we increased our knowledge and that this will help us improve the way we work. Kent Beck, the creator of Extreme Programming, started the event with a live-video about “Jazz and Classical: Same Instruments, Different Style”. Everyone was quite happy with Kent’s sharing of Convexity & Concavity. Many interesting topics were presented, but I would like to re-share The Art of Writing User Stories and Things you should know to be a professional Developer.

 

1- THE ART OF WRITING USER STORIES

 

The user story is one of the most important steps when it comes to the development process with agile methodologies. Working with a user story may be easy but writing it can be hard.

To have a good user story, we need to understand what the customer wants and deliver exactly what he wants, so communication is a must. It sometimes happen that clients don’t know what they want exactly, so the job of a QA guy is to verify the requirements of the PO and make sure that all the necessary functionalities are mentioned and that they are mentioned in the right order.  

A good advice would be that the product owner and the QA write user stories together. Different roles in the team can contribute with their expertise and ideas to build a good user story and they will therefore be on the same page: what’s the purpose, what to build, how to build it, when to build it, etc. It can take time in the beginning, but it has huge value because the team can go ahead and deliver what the user really wants.

What should a beginner user story writer know?

 

USER STORIES NEED TO BE CONFIRMED BY THE “3C GUIDELINES”  by Ron Jeffries

 

  • CARD: User stories are traditionally written on index cards or sticky notes, in short forms. User narratives further explain these cards. Thus, the main intention is to describe the user story in short form to allow common understanding of the user need among all stakeholders.
  • CONVERSATION: User stories shift the focus from writing about features to discussing them. In fact, these discussions are more important than whatever text is written.
  • CONFIRMATION: Acceptance tests confirm that the story was delivered correctly.

 

USER STORIES SHOULD ANSWER 3 QUESTIONS

 

  • Who are we building it for? Who is the user? — As a <type of user>
  • What are we building? What is the intention? — I want <some goal or objective>
  • Why are we building it? What value does it bring to the user? — So that <benefit, value>

Sample sentence:  “As a ____, I want ___, so that ____

 

START WITH EPICS

 

  • Epics are high level features or activities from customers, that can’t be completed in a week.   
  • Rule of thumb is, if there are more than 5 user stories, of same focus area in a project, then it’s good to create an epic and attach all five of those user stories to that Epic.
  • Epic is just a placeholder which can hold multiple user stories which are focused on specific scope, think of epic as a book and user stories as its’ chapters.

 

FOLLOW THE “INVEST” GUIDELINES FOR A GOOD USER STORY 

 

  • Independent – Don’t mix user stories together, each should be independent.
  • Negotiable – Make sure your stakeholders understand that often user stories must be discussed based on elements and both you and the client may have to learn how to agree to disagree.
  • Valuable – If the user story is too vague, it won’t be helpful.
  • Estimable – User stories may have to be prioritized.
  • Small – Keep them short, user stories are not novels.
  • Testable – Make sure the user story actually offers something you can analyze or test.

 

2 – THINGS YOU SHOULD KNOW IF YOU WANT TO BE A PROFESSIONAL DEVELOPER

 

TEST DRIVEN DEVELOPMENT

TDD is the core part of the agile code development approach from Extreme Programming (XP) and the principles of the Agile Manifesto.

Six fundamental steps of TDD

  1. Write a test for a piece of functionality
  2. Run all tests to see the new test should fail
  3. Write code that passes the tests
  4. Run the test to verify they pass
  5. Refactor the code
  6. Run all tests to see if the refactoring did not change the external behavior

 

What are the benefits of TDD?

  • Simpler Development Process
  • Improved Communication
  • Improved Understanding of Required Software Behavior
  • Reduced Design Complexity

 

Available TDD Tool list  

csUnit (.Net), CUnit, DUnit (Delphi), DBFit, DocTest (Python), Googletest, HTMLUnit, JMock, JUnit, Moq, NDbUnit, NUnit, OUnit, PHPUnit, PyUnit (Python), SimpleTest, TestNG, TestOoB (Python), Test::Unit (Ruby), VBUnit, XTUnit, xUnit.net

 

PAIR PROGRAMMING

 

PP is an agile software development technique in which two programmers work together at one workstation. Both programmers concentrate on the code being written.

It takes time to learn, but benefits we gain are valuable. It will be much higher in quality. This implies big savings later in the project.

 

Benefits of PP

  • Many mistakes get caught as they are being typed in, rather than in QA test or in the field (continuous code reviews)
  • The end defect content is statistically lower (continuous code reviews)
  • The designs are better and code length shorter (ongoing brainstorming and pair relaying)
  • The team solves problems faster (pair relaying)
  • The people learn significantly more, about the system and about software development (line-of-sight learning)
  • The project ends up with multiple people understanding each piece of the system
  • The people learn to work together and talk more often together, giving better information flow and team dynamics
  • People enjoy their work more

 

BEHAVIOUR DRIVEN DEVELOPMENT

 

BDD is a new Agile methodology and it helps developers, testers and business analysts share a common language through a good focus on business requirements.

A BDD approach helps increase business agility and align and prioritize IT initiatives with business imperatives. It also indirectly helps to simplify the cost justification process for IT budgets inside an organization.