The Six Attributes of a User Story and Why They All Count

The current best practice in Agile Software Development to clearly and briefly describe the functionality from the end-user’s perspective is the User Story. High quality User Stories will become part of the product backlog iteration. Weak User Stories are a waste of time and should be avoided at all cost.

This article will teach you the six attributes every effective user story must possess to pass the backlog quality check and ensure you spend your time right.

 

The INVEST Mnemonic To Writing High Quality User Stories

This simple, yet profoundly powerful mnemonic is a creation of Bill Wake the co-inventor of Extreme Programming.

I = Independent

A great User Story has the potential to stand for itself. By following this criterion the story can be scheduled and implemented in any desired order. This makes the story usable in different contexts and for multiple concepts.

N = Negotiable… and Negotiated

Outstanding User Stories are co-created by the programmer and the user. Only the main essence is captured, while the details are steadily added and influence the whole backlog in an iterative manner.

 V = Valuable

All great stories add specific value to their target audience, in this case: the user. Especially when splitting stories, each individual piece should address one very specific area in which value is created, while telling the overall conceptual story.

 E = Estimable

Every User Story must be estimable in order to be considered for a ranking by the customer. The degree of ratability is directly linked to the story being negotiable. Only stories that are understood by all stakeholders are estimable in scope and budget.

S = Small

A Story should not be overwritten and only focus on one key value adding idea. Keeping it within the range of a few person-days and at most a few person-weeks ensures that the story will be estimable.

T = Testable

Stories must be testable in order to be considered for the product backlog. If a story is not testable due to a lack of information it probably is not estimable and does not provide specific value to the customer.

All of the six attributes have to be considered in order for the User Story to be implementable. They affect each other in an iterative manner. Shortcomings in one area may lead to an information deficit in another and towards an unusable story.

 

Take the time to check your User Stories for all of these attributes. Time has shown that a Feedback Circle of Proposing – Estimating – Implementing is the most effective way to produce a great User Story, implementable in many different contexts.

Where to with the user story when completed

A user story is typically functionality that will be visible to users, by users this includes end users, administrator’s manager. To create a user story will require a number of tasks to be completed. These tasks are often shared out among a range of people such as analysis’s, designers, programmers and testers so each has their own task. When put together the tasks complete the user story.

 

User stories appear on the Product Backlog and tasks appear on the sprint backlog.

Include INVEST workshops as part of good Scrum Master training and coaching.

Programme Management

I’m currently working with a multinational organisation to build out the strategy to empower the business to take advantage of new regulations coming in as a result of de-regulation in Europe (Hmmm). We are working on a Programme to implement the strategy to deal with these changes in our marketplace.

 

For me Programmes are not just a collection of related projects it’s significantly more than that, programmes are about strategy and projects are about tactics.  Programme management is overseeing the implementation of a set of related projects and activities in order to deliver outcomes and benefits related to the organisations strategic objectives.

 

Programmes deal with outcomes and projects deal with outputs (From MSP®). We do use Programme Management to coordinate related projects but that’s down the road and its not the primary reason to kick off a programme. The programme starts by taking the business strategy, targets, initiatives and policies and defining the vision, scope and priority of the outputs that will deliver the outcome.

How do we approach this.

Develop the Vision, this is the postcard from the future of state of the business. It is used as the focus for the programme and like any vision it should be compelling and clear. Failure to get a good visions statement weaken the programme, therefore time should be spent in developing it. Re-design the vision in the middle of the programme may cause confusion.

 

From a Vision we can tease out a target operating model for the future, the practices and process that will be need to be in place to deliver the vision.  The target operating model is the blueprint of the future and the programme manager has the responsibility to ensure that the blueprint is delivered.

 

The POTI model is useful in developing out the blueprint, for each element of the blueprint used it to analyse the processed, organisation change, technology and information required for the future

 

 Detail
Vision StatementWe want to enter new emerging market ABC
                PProcesses, Business Models of operations and functions including operating costs and performance levels
                OOrganizational structure, staffing levels, roles, skills required, organizational culture, supply chain and style
                TTechnology, buildings, IT Systems and tools, equipment, machinery and accommodation
                IInformation and data required for future operations

 

From defining these process, organisational changes, technology and Information the projects to deliver them become apparent.

The above is simplified method bases on MSP®. More details on the methodology is available with templates examples. Drop me a line to chat through it.

Agile Practiitioner

The PMI-ACP is not difficult  but it does throw up some strange questions as the PMI try to relate the traditional PMP material to the  Agile methodologies. Many of the analysis techniques like  earned value are difficult to related to software development in a waterfall environment and applying them to agile seems like an unnecessary overhead we have no BAC.  The good news is that it is all due to change.

The current exam focuses on Scrum , Lean, Agile Concepts (the manifesto)  Kanban and XP and then mixes them up to create situation questions relating to general management or Project management (servant leader, Emotional intelligence etc.)

Mike Griffiths book is still the best general book, though I don’t think it gives Lean the coverage that is needed for the ACP Exam. Be careful with the online PMI-ACP exam question available online as  many of them are absolute rubbish, frustratingly written in an unknown dialect of English with confusing or completely incorrect answers.

The Velocitech website is probably the best set of exams out there and Andy Crowe’s  book is a good reference book with exam questions for the ACP exam but it is not a complete guide.

I do suggest that you research Mike Coen (Scrum) and  Mary Poppendieck (Lean) material. Their  publication,  webinars and blogs are a good source. Ken Schwaber book the “the art of doing twice as much in half the time” is worth a read for motivation though not particularly useful ACP

The books if you have the time are;

    • User Stories Applied: For Agile Software Development – Mike Cohn
    • Agile Software Development with Scrum – Ken Schwaber & Mike Beedle
    • Extreme Programming Explained – Kent Beck
    • Agile Estimating and Planning – Mike Cohn
    • Lean Software Development: An Agile Toolkit – Mary & Tom Poppendieck
    • The Art of Agile Development – James Shore;

The Project Management Institute suggests a number of others on their website. These have changed from the previous exam  with 4 new books added and 4 removed. 2 are on Kanban alone.

The exam time is 3 hours with most of my student competing it in 1.5 hour and many in less than an hour. The question are not as tricky as the PMP exam, correct answers are more obvious and less where the answer required is the ‘‘best’ or ‘first’. Moving from agile concepts will catch you out, one minute we are taking about the customer, the next it’s a product owner and the next question may be from the point of view of a Project Manager.  

The course is a good course to get yourself up to speed as a traditional project manager, a middle manager or perhaps as a product owner. For developers or budding Scrum Masters It may not provide the level of detail and doesn’t deliver the ‘fun’ experience that agile encourages.

The course is changing with a different approach. It looks to me like it will concentrate more on the approach and mind-set and less on the specific concepts.  I suggest that it will aligned with the directions that the PMI have for the skills of  a combination of technical, leadership, and strategic and business management expertise

The new PMI-ACP exam will see a number of changes (PMP Exam Content Outline,) summarised below

There are sever domains of Agile practices

    1. Agile Principles and Mindset
    2. Value-driven Delivery
    3. Stakeholder Engagement
    4. Team Performance
    5. Adaptive Planning
    6. Problem Detection and Resolution
    7. Continuous Improvement (Product, Process, People)

The distribution of questions on the PMI-ACP exam paper are now based on the domains

  1. Agile Principles and Mindset – 16%
  2. Value-driven Delivery – 20%
  3. Stakeholder Engagement – 17%
  4. Team Performance – 16%
  5. Adaptive Planning – 12%
  6. Problem Detection and Resolution – 10%
  7. Continuous Improvement (Product, Process, People) – 9%

New Tools and Technique / Knowledge and Skills are added while many are removed from the new PMI-ACP exam syllabus. New items added including:

    1. Developmental mastery models (for example, Tuckman, Dreyfus, Shu Ha Ri)
    2. Participatory decision models (for example, convergent, shared collaboration)
    3. Agile hybrid models
    4. Managing with agile KPIs
    5. the Five WHYs
    6. retrospectives, intraspectives
    7. control limits
    8. pre-mortem (rule setting, failure analysis)
    9. fishbone diagram analysis
    10. minimal viable product (MVP)

Althris Training have worked with our partners to redevelop our course material for the new ACP exam. To keep you posted and get more updates on both drop me an email

Does ‘servant leader’ sound strange to you? After all, does it make sense to talk about leading a team so that it moves forward to achieve goals, while being behind it to tend to the wants and needs of team members? Yet in numerous project management situations this style of leadership can be very effective. What might look like incompatibility at first blush becomes a doubly positive force for obtaining better results faster and more efficiently.

Agile project management methods like Scrum are a case in point. Handling change and rapid development cycles requires intelligence and creativity from team members. Leaders that try to pull rank are likely to do more harm than good. On the condition that everybody understands the basic rules of engagement, the contributions to be made and the objectives to be met, hierarchical levels can be taken out of the equation.

A servant leader then:

  • Assures the well-being of the team and team members
  • Prioritizes his or her own actions to help team members solve problems (without dictating the solution)
  • Focuses on people, on the understanding that well-motivated and enthusiastic people will meet project targets and expectations best.

At the same time, the servant leader is also the lynchpin for communicating with sponsors, stakeholders and other management. This is as challenging as any other leadership approach. That means good servant leaders are usually the ones that have had the right training and experience. And the right training also instills the recognition that servant leadership is one possibility among several, to be applied as and when the situation calls for it.