-
Notifications
You must be signed in to change notification settings - Fork 82
Agile Project Execution
You can find here the document used in today's team meeting: Agile Project Initiation
Before generating good stories, the vision of the product/project must be clearly stated to every participant. From the vision we can derive features. The features are the goals necessary to accomplish the vision. After gathering all/many features, it is the goal (of the Product Owner) to define the MVP (Minimal Viable Product), i.e. to select those features whose completion would generate the greatest value for the business. Note we also introduced the name epic which can be used interchangeably with feature.
From the features we can derive stories. A story provides all the information necessary for the dev team to implement it within one iteration. If a story is selected for an iteration, the dev team breaks it into tasks which are then being worked on during the iteration.
Basically, we have several business models, but the research model is the most prominent one since it actually generates a revenue for us, i.e. third-party funding. This is something we need to keep in mind as it generates big uncertainty for our projects because it involves research which cannot be well estimated well due to its nature.
That means that features can be selected in a way that they result in a publication rather than a full functioning product. Why is this important? Because it affects the personas and the structure of the stories as we will see in the following.
A feature should describe in a few sentences the three key points that are relevant in order to decide if it is part of the MVP or not. These three key points are the who, the what, and the why.
- Who: "As a [persona]": Who are we building this for? We're not just after a job title, we're after the persona of the person; let's call them Max. Our team should have a shared understanding of who Max is. We've hopefully interviewed plenty of Max's. We understand how that person works, how they think and what they feel. We have empathy for Max.
- What: “Wants to”: Here we're describing their intent — not the features they use. What is it they're actually trying to achieve? This statement should be implementation free — if you're describing any part of the UI and not what the user goal is, you're missing the point.
- Why: “So that”: How does their immediate desire to do something fits into their bigger picture? What's the overall benefit they're trying to achieve? What is the big problem that needs to be solved?
The "As a [role] I want [feature] so that [reason]." pattern can be used to focus on the three key points to extract the important information. I think we should strive for this pattern as often as possible but it also turns out that this is not an easy task. The biggest problem I see for our project structure is to define the persona. It should not be the rather unspecific "user" (see above). But for many projects complete work packages have already been worked out which are then refined by one or more features. Some of them also include research aspects as stated above. This makes it hard to convey the information in the given format. One approach would be to make the researcher a role and describe the feature from this perspective.
Another approach would be to use a different template: [action] the [result] [by|for|of|to] a(n) [object]
So it could be something like: Research|Investigate a better algorithm to get a bin division with a smaller effective text ratio then using naive bin division.
This still can be broken further down into stories and put into the global scope of the other stories and features.
A story adds another level of refinement. If you will, you can call a feature/epic a story as well, but on this level there is a fundamental difference. In a story there is more discussion about a feature and its requirements. Agile management tries to avoid the mentality of "I specify everything at the beginning of the project". It rather tries to defer the specification of the requirements up to the point where they are actually needed. As for the workflow, let's assume a specific feature has made it into the next release plan. This means the team will ask all possible questions about the feature that helps them to fully understand the scope of it and to see what the product owner actually wants. This also involves the conditions of satisfaction and the behaviour on error conditions. Based on that, more fine grained stories for this feature are verbalised (but still no implementation details, they only become relevant when splitting stories into tasks). Accordingly, the following acronym is advertised as a measure for a good story:
- I - Independent: The story should be self-contained, if at all possible, to avoid dependencies on other stories.
- N - Negotiable: User stories can always be changed or rewritten up until the point of coding.
- V - Valuable: A story represents a goal of an end user (remember that we need to find our roles!) and should deliver functionality that is deemed valuable.
- E - Estimable: You should always be able to estimate the size of a user story (something that will come later).
- S - Sizeable: User stories shouldn't be too big or too small.
- T - Testable: User stories must be testable in order to ensure that development is complete and has been done correctly.
While it is still valid to apply either template: As a [...] I want [...] such that [...]. or action result object, I have seen examples where there was no strict format for this level of requirement description. I believe that this is easier for us in our project structure at the moment since the general information are already conveyed through the associated feature/epic. That of course does not mean that there can't be a single self-contained story without an epic. But then the information should be clear on that. As I said, the differences between feature/epic and story are subtle, but nonetheless they describe different states of requirements and thus different times in the project planning.
So I guess something like Compute a multiple sequence alignment for genomic sequences and break them into bins by the biggest overlaps. (sorry if not accurate) could be a story for the above mentioned feature.
On these kind of stories we can note the acceptance criteria which will make up the definition of done. So when all acceptance criteria are fulfilled, this story is done. The story should (if possible and something we should strive for) be of a size such that the team can develop it in one iteration after they defined all tasks to implement and test that story. There are several techniques to split a story into smaller ones. But this will come later. There might also be stories that are pure research tasks. These can still be reflected in the project planning part but might not necessarily be constrained to be done in one iteration. Maybe they provide valuable insight for stories that follow this research iteration, maybe more research must be done. Let's see. :D
In the following I just started to write up the stuff I read about. This is in no particular structure or format. So you can but don't have to read the following parts.
Some words before. Out of real life experiences we decided to change our project planning/execution to be more agile. There is no standard agile way that fits all. So instead of following a plain text-book approach it is important for every agile team/project to evolve over time. There are however, certain paradigms and techniques that are well spread in the agile community. Thus, since we are at the beginning of our journey to become more agile (note, that per definition this journey will never end), we will follow a text-book design from "The Agile Samurai". This only the first book related to this topic. More approaches will be probably tested and refined over time so stay tuned.
The first really important information for everyone to understand is: There is no I. There is only a we. We as a team decide... We as a team implement... We as a team request... etc. A single person can only provide as much value to the whole project as the entire team understands it. Otherwise, there is no knowledge transfer. Nothing that will be sustainable. But that is exactly what we want!!! Also it is very beneficial if the team is co-located.
Here is broad description about typical roles in an agile team.
- The agile customer: "source of truth", for whom the software is built
- The agile analyst:
- The agile programmer:
- The agile tester:
- The agile project manager:
There is no clear role that anyone in the team has. Every team member should be able to perform any of the role's tasks described above (except maybe the product owner which has a very specific role).
Who is involved in the project but not necessarily permanent on the team but a great deal of the project depends on them anyhow?
- IT: The IT is responsible for a working infrastructure. They are responsible for server health and accessibility. They can provide additional build resources. They are responsible for installing latest compilers etc. So it is important to see them as part of the project team.
Need to be decided by the team!
Estimating the amount of work is the hardest task within every project and most often people fail to give correct estimates. The key point is that we do not estimate person-days or person months but we estimate relatively using story points. We will start with 3 story points: 1 - 3 - 5 1: easy task (within 1-3 days) 3: intermediate task (within one week) 5: heavy task (within one iteration)
If the team estimates something higher than 5 - it will become an epic. A story that the team needs to break down and will take longer than one iteration to be finished.
How to estimate: By reference. We take examples we already completed and use those as relative estimates for 1,3,5. Also in the sprint planning meeting the team plays estimation poker. [TODO] write me
Are defined by delivering something of value at the end of every cycle. Require well formulated user stories. But the in depth-analysis of the stories is first done at the latest point before the iteration it is worked on. Start with a 2 weeks iteration phase. Ensure a tight feedback loop with the customer. Ultimately, they decide if there are changes to the plan once they got the first things to work with!
Who should participate: The development team, The product owner, optimally the customer Just-in-time analysis of the next stories on the backlog with the highest priority. Update the plan accordingly
Who should participate: The development team, the product owner, optimally the customer The team decides what they can take on in the next iteration and stays flexible in this time. Vacation, workshops, conferences, etc.
Review team's velocity Review upcoming stories Decide what is getting into the next iteration Give a quick whether forecast: How is the project health. How are we doing for the release etc.
10 - 15 minutes: Where are we kicking butt and where we need to impove
Demonstrate the user what the new features can do. Some ideas I have are: make small things visible via twitter/blog entries. Organise maybe 4 times a year a meetup and invite people to demonstrate the software more elaborated. Using the developer/user workshops.
Update of your current work progress. Mostly focus on something that is interesting for the team. For instance I thought I can do it like this but it turns out there is an issue with this etc. So focus more on the stuff that you have problems with. Also maybe follow this template:
- What you did to change the world yesterday
- How you are going to crush it today
- How you are going to blast through any obstacles unfortunate enough to be standing in your way
- probably trello
- Visualise in Github
- The stories we planned for the release (in the story gathering workshop)
Visualise in GitHub
- The items we are processing in the current iteration.
ZenHub has great toolings to help us to setup the boards for a clear visualisation.