Sebastian Durandeu Blog

  • Visitantes

Archive for the ‘Project Management’ Category

Fearless Change by Mary Lynn Manns and Linda Rising

Posted by sebastiandurandeu on October 30, 2010

fearlessChangeConocí este libro por Juan Gabardini, en la materia Administración y Control de Proyectos II de la FIUBA.

Fearless change: Patterns for Introducing New Ideas es un libro sobre patrones; patrones sobre como impulsar un cambio en una organización, ya sea desde lograr un reemplazo de la maquina de café, hasta modificar por completo la forma de trabajo de la organización.

Los patrones están basados en el estudio del comportamiento humano y las interacciones. Si bien el libro parece tener una clara orientación ágil (no lo leí aún), los patrones son genéricos y y pueden ser aplicados a cualquier tipo de organización o grupo de personas en cualquier contexto.

Recomiendo mucho mirar la entrevista de InfoQ a una de las autoras, Linda Rising, en la cual presenta el libro a través de claros ejemplos de como convencer a sus compañeros de trabajo de empezar a trabajar de forma agil. Quedé impresionado en las cualidades de presentadora de Linda Rising y cuan naturalmente introduce los patrones en su discurso.

Para darnos una mejor idea, dentro de los patrones que el libro explica están:

  • Do Food (o Brown Bag): Llevar comida siempre es una buena opción para atraer gente.
  • Just Do It: Arrancar por casa. Si quiero introducir un cambio probarlo yo primero.
  • Ask for Helper: Solo se complica, no olvidar que se puede pedir ayuda a otros, en particular a los Innovators (otro patrón), que son los compañeros a los cuales les suelen gustar las nuevas ideas.
  • Piggyback: Siempre es mas fácil sumarse a algo existente, tratar de introducir las prácticas nuevas como mejoras a prácticas existentes en la organización.
  • Local Sponsor: Si tengo el apoyo de algún jefe también es mas fácil introducir nuevas ideas.

Posted in Agile, Libros, Project Management | Leave a Comment »

Writing User Stories

Posted by sebastiandurandeu on March 26, 2010

El objetivo de este post es tener una referencia rápida de que cosas tener en cuenta para escribir User Stories (en inglés):

  • User Stories General Guidelines
    • Each story must be written in the language of the business, not in technical jargon. They should be comprehensible by both the developers as well as the customer team.
    • Each user story represents a discrete piece of functionality; that is, something a user would be likely to do in a single setting.
    • A user story is short and concrete, something like:

      ”A user can view detailed information about a company that has posted a job.”
      More details about the story can be written in the form of user acceptance tests, that is reminders of how to test a story, and attached to the story. For example:

    • Test with empty job description.
      Test with really long job description.

    • Acceptance testing is the process of verifying that stories were developed such that each works exactly the way the customer team expected it to work.
    • To create good stories we focus on six attributes. A good story is (INVEST):
      • Independent
      • Negotiable
      • Valuable to users or customers
      • Estimatable
      • Small
      • Testable
    • Ideally, stories are independent from one another. This isn’t always possible but to the extent it is, stories should be written so that they can be developed in any order.
    • The details of a story are negotiated between the user and the developers.
    • Stories should be written so that their value to users or the customer is clear. The best way to achieve this is to have the customer write the stories.
    • Stories may be annotated with details, but too much detail obscures the meaning of the story and can give the impression that no conversation is necessary between the developers and the customer.
    • One of the best ways to annotate a story is to write test cases for the story.
    • If they are too big, compound and complex stories may be split into multiple smaller stories.
    • If they are too small, multiple tiny stories may be combined into one bigger story.
    • Stories need to be testable.
  • User Story Size
      1. Agile Theme. A set of user stories related.
      2. Agile Epic: Large user story. For a feature that you want eventually but that isn’t important right now, you can first write a large story (an epic). When you’re ready to add that story into the system you can refine it by ripping up the epic and replacing it with smaller stories that will be easier to work with.
      3. Agile User Story
      4. Agile Task
    • It’s good to have stories that can be coded and tested between half a day and perhaps two weeks by one or a pair of programmers.
    • User Stories categories by size:
  • User Story Roles
    • Each story should be written from a perspective of a user role. As part of the process of writing stories, you should identify all the user roles who will interact with the software.
    • A user role is a collection of defining attributes that characterize a population of users and their intended interactions with the system.
  • User Stories Estimations Techniques
    • Expert Opinion
    • Analogy
    • Disaggregation
    • Planning Poker: Mix of three. Based on the Delphi method.
  • User Stories Estimation Scales
    • Fibonacci (1,2,3,5 + 8 ) –> Story Point Estimation
    • Power of 2 (1,2,4 + 8 )
    • T-shirt Sizing –> For estimating Epics

Using Points makes the unit of estimation abstract, which makes it easier to commit to, and easier to adjust your commitments to. Points are an abstract number. They do not convert to a unit of time. They are simply a *relative* indication of size.

The non-linear sequence work well because they reflect the greater uncertainty associated with estimates for larger units of work.

  • Team Velocity
    • The amount of score completed by the team after one iteration.
    • The team’s first estimate of velocity will be wrong because there’s no way to know velocity in advance.


Posted in Project Management, SCRUM | Leave a Comment »